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one or more target applications of interest an ATU is 
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tested. The knowledge of how a given UI element is 
controlled or how it can be observed is retained in the model 
rather than in a test script Coosequcndy. the test script 
consists of easy-to-maintaiiL high-level testing commands 
only. 
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SYSTEM AND METHODS FOR IMPROVED 
PROGRAM TESTING 

The present appUcation is a continuation application of 
appUcaUoD Ser. No. 08/140,904. filed Oct. 21, 1993, now 
U.S. PaL No. j. 475,^43. which is a oontiauatioc-lD-pan of 
application Scr. No. 07/970.724, filed Nov. 2, 1992. now 
U.S. PaL No. 5.432,940. 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
rqroduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

BACKGROUND OF THE INVENTION 

. The present invention relates generally to system and 
methods for testing reliability of software programs. More 
particularly, the present invention relates to a con^ter- 
aided software testing system and methods which assist a 
Quality-Assurance engineer and software developen with 
the testing of Graphical User Interface (GUI) software 
programs operative on digital computers. 

Development of software is largely a trial and error 
in-ocess. Accordingly, substantial development resources are 
allocated to the process of finding "bugs** — errors occurring 
in the program being developed. Expectedly. there is keen 
interest in finding ways to Improving the testing of software. 

As software is developed on and runs on conqxitcrs. it is 
not surprising to find that many of the te^niques fc^ 
automating the testing of software have been implemented 
in digital computers. A common approach for testing soft- 
ware is the use of test suites. Test suites compare ''known 
good** outputs of a program (for a given set of ii^ut) against 
the current output Tests that check program file output are 
easy to implement and can be automated with shell scripts 
(e.g.. Expect available on the Internet). For programs with 
user interfaces that conuxmnicate to standard input/ouQnit 
devices (stdin/stdout). a similar method may be onpioyed. 
Opture^layback tools are available for recording keyboard 
input and program output as a perscm tests a program. 

Much of the code written today is for software products 
with a graphical user interface (GUI), such as Microsc^t® 
Windows™. In fact, much of software development itself is 
done within a graphical user interface, with software tool 
vend<Hs providing products which allow software dcvelop- 
Q-s to devel<^ GUI software using visual programming 
techniques. The Quality Assurance (QA) engineer faces 
more complex problems when testing GUI software. In 
particular. GUI ivograms must behave correctly regardless 
of which video mode or operating environment is being 
employed. 

Intuitively, testing user interfaces should not be as difficult 
as testing a complex internal engine, such as a compiler or 
a real-time, multi-user operating system. In practice, 
however, user interface (UI) testing is the most challenging 
part of the QA process. This problem stems Isigcly from the 
difficulty in automating UI tests. Tests for complex engines, 
in contrast, are often commaod-line programs whose testing 
can easily be automated using simple batch execution. Thus 
despite the plethora of present day tools for automating 
program testing, the task of developing, maintaining and 
analyzing the results of UI tests remains an arduous task. 



2 

The basic steps traditionally employed to test user inter- 
faces may be summarized as follows. First, the application 
being tested is controlled by placing it into a specific state 
using either pre-recorded keyt>oard or mouse device actions. 
5 or entering input through a test script Next, the then-cuiient 
state of the application is recorded by taking a screenshot 
(e.g.. capturing a screen bitmap). Finally, the captured 
screenshot is compared with a baseline screenshot that is 
known to t>e valid. 

The appffoach is far from ideal, however. Consider, for 
instance, the determination of whedier die state of a dieck 
box is valid within a specific dialog box. Here, the QA 
engineer must take a screenshot of that check box and 
conq>are it with the expected image. Thus, testing of even 
the simplest component is laborious. Moreover, the 
approach itself is prone to error. A change of just a few pixels 
across all windows — a common occurrence in GUI software 
development— causes, all tests to fail. Consequently, as 
software becomes more and more complex, it becomes less 
^ and less feasible to test user interface tasks with present-day 
screen comparison methodology. A better approach is 
needed. 

SUMMARY OF THE INVENTION 

The present invention includes, in a first embodiment, a 
Con^njter-based Training system (CBT) having one or more 
Application Translation Units (ATUs), a Message Engine, 
and a Script Engine. Specific operation of the system is 
directed by a series of user instructions, typically provided 

^ by a tutorial writer. Within the script links are established 
between the CBT system and one or noore target applications 
of interest. Specifically, within a particular ^iplicatioo links 
are established with individual controls (eg., menu items, 
button controls, dialog boxes, and the like) so that the script 
writer has complete control over the behavior and actions of 
the target plication. 

For each targ^ plication of interest, an ATU is provided 
for processing events ^cific to that ^iplication. A general 

^ OpCTating System (OS) ATU is also provided for trapping 
general system events. The ATUs function to trap events and 
translate them into abstract messages or *'meta-mes sages** 
for conveying information about a particular event to the 
system. In this manner, low-level messages arc abstracted 

^ into high-level, more meaningful messages which may be 
acted upon through the script 

Translated event messages are forwarded to the Message 
Engine for matching with event handlers. In a preferred 
embodiment, the Message Engine maintains a lookup table 

^ for matching messages with a desired target handler. System 
or application- specific messages which are not of interest are 
simply allowed to pass through. From the Message Engine, 
the individual handlers dispatch their respective messages to 
the Script Engine The Script Engine, in turn, matches an 

j j incoming message with reserved words of the script. Appro- 
priate action, based upon use of the reserved word within the 
script, is then effected. 

A software testing automation embodiment of the present 
invention is also described. The system includes a Generic 

£0 Element Models (GEMs) library. Application-specific Test- 
ing Models (ATMs), a Resource Database, one or more 
Model Generators, a Test Runtime Library, as well as the 
above-meotioned Script Engine, Message Engine, and 
Aj^Ucatioo Translation Units (ATUs). 

65 The system employs the Model Generator to decompose 
the application under test to generate die ATMs. Each ATM 
is a high4evel model for a specific' component of the 
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applicatioD being tested, such as a File Open dialog. ATMs 
describe the actual compooent which they represent in terras 
of Generic Element Models (stored io GEMs Library). A 
GEM CDcapsiilates the behavior of irreducible user interface 
eiemcnts such as push buttons, checkboxes. li5tboxc5. and s 
the like. Knowledge of how a given HI clement is controlled 
or how it can be observed is retained in the model rather than 
in a test script. This high-level nK>del serves as a middle 
ground bctwccD test scripts and the application being tested. 
In this fashion, a script for testing operation of a program lo 
need only consist of casy-to-maintain. high-level testing 
commatids. 

During operation, the system maintains an in-memory 
Testing Model of a particular ^^lication under test. Overall 
operation of the system is directed bry one or more test 15 
scripts. GEMs are instantiated when an ATM cocre^nding 
to an active state of the application under test is activated by 
die Model Manager. GEMs load their expected results from 
the Resource Database and are cf^able of binding them- 
selves dynamically to the actual object on the screen which 20 
they represent Each GEM thacfore can pcrfonn a **sclf 
test** on itself by suofiy comparing its expected result (as 
stored in the Resource Database) to its actual bdiavior (as 
displayed on the screen at runtime). In this manner, an entire 
application can perform a self test by simply asking all its 25 
components to test themselves in turn. 

GEMs of the present invention provide maximum con- 
trollabdlity and observability over the actual screen objects 
that they rqjresent By breaking the user interface down into 
ixreduc^le components which arc modeled to provide maxi- ^ 
mum controllability and observability (over the actual 
screen objects that they represent), the Test Model created 
provides maximum controllability and observability. 
Accordingly, testing effectiveness is maximized. 

BRIEF DESCnUFnON OF THE DRAWINGS 

FIG. LA is a block diagram of a computer system in which 
the present invention may be cnsbodied. 

FIG. IB is a block diagram of a software system of die 
present invention, which includes operating system, appli- 40 
cation software, and user intexface con9>onents. 

FIG. IC is a bitmap screenshot illustrating the basic 
architecture and functionality of a graphical user interface in 
which the present invention may be embodied. 

FIG. 2 is a pair of flowcharts contrasting the operation of ^5 
conventional modal architecture with that of event-driven 
architecture. 

FIG. 3 is a block diagram of a Computer-based Training 
(C!BT) system of the present invention. 

FIG. 4A is a flowchart illustrating a method of the present 
invention for operating the (ZBT system of FIG. 3. 

FIG. 4B is a flowchart illustrating the operation of hooks, 
dispatchers, and handlers of the method of FIG. 4A. 

FIG. 5A is a flowchart illustrating die operation of an 
exemplary event handier of the present inventioo. which 
includes the dispatching of event information (Eventlnfo) 
objects. 

FIG. 5B is a flowchart illustrating a method of the present 
invention for dispatching meta-messages. ^ 

FIG. 5C is a class hierarchy diagram illustrating the 
underlying structure for the Eventlnfo objects of FIG. 5 A. 

RG. 6 is a Uock diagram of a computer-aided software 
testing system of the present invention. 

FIG. 7 A is a bitmap screenshot illustrating a screcD dialog 63 
object (box), which includes children components (e.g.. 
screen buttons). 
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RG. 7B illustrates the relationship between the dialog of 
FIG. 7A and underlying resource information (which origi- . 
□ally had beeo provided by the programnKr creating the 
application). 

FIG. 7C is a diagram illustrating the relationship between 
resource information (represented in Microsoft Windows 
resource format) and the runtime API Windows call 
(Create Window), 

FIG. 8A is a bitmap screenshot illustrating Not^d — a 
simple Windows application for illustrating operation of the 
system of FIG. 6. 

FIG. 8B is a diagram illustrating resource information for 
a screen menu of die qiplication of FIG. 8A. 

FIG. 8C is a flowchart illustrating a method of the present 
invention for decon^x)sing (extracting) menu information 
for the Notepad application. 

FIGS. 8D-E arc diagrams illustrating the relationship 
between resource information (however extracted) and 
Application- specific Testing Models (ATMs) constructed by 
the system of the present invention. HG. 9A is a bitmap 
screenshot illustrating a File Open dialog of the Windows 
Notepad qjplication. 

RG. 9B is a bitmap screenshot illustrating children com- 
ponents (e.g., screen buttons, combo boxes, and list boxes) 
of (he dialog of FIG. 9A. 

RGS. 9C-D comprise a flowdiart illustrating a method of 
the present invention for decomposing dialog information 
for the Notepad application. 

GLOSSARY OF TERMS 

CBT: Computer-based lYaining; the use of computers and 

spedally designed tutorial programs for teaching. 
CBT Message: A high-levd or nacta-mcssagc describing or 
encapsulating information about a partictilar event which 
has occurred, thereby allowing the user to abstract low 
level system messages into high level (and more 
meaningful) messages for scr^t control. 
CBT Object: An object, such as a C++ object, which can be 
placed in a Dynamic link Library (DLL) and dynamically 
loaded when the tutorial is executed. 
Control Window; A CBT object which is used for getting 
information from the user; typically, it includes a window 
having a number of dialog controls. 
Interaction Objects: CBT objects which are used to interact 
with the USCT. These objects include Presentation 
windows. Control windows and message handlers. 
Lesson Script: Script statements which control the execution 
of the CZBT tutorial. Each lesson includes a collection of 
Scenes. 

List: A container object which is used to hold unorganized 
data. 

Message Handler: A CBT object which interacts with the 
target application. These objects are used to handle exter- 
nal events. 

Object Property: An attribute or other data associated with a 
particular object, for example, name, title, color, and the 
Uke. 

Performance: The execution of a CBT Scene by the CBT 
system 

Scene: A script object which describes the actions to perform 

at a particular point in the CZBT lesson. 
Script: A collection of statements which arc understood by 

a Script Engine. 
Windows Hook; A function installed b^een the Wmdows 
OS and an application to intercept Windows events before 
they are received by the application. 
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DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

The following descriptioo will focus on the prcscotly 
preferred embodiment of the present invention, which is 
operative in the Microsoft® Windows environment. The 
present invention, however, is not limited to any paitlcular 
one application or any particular windows environment 
Instead, those skilled in the ait will find that the system and 
methods of the present invcation may be advantageously 
^lied to a variety of system and application software, 
including database management systems, worc^rocessors, 
spreadsheets, and the lilcc. Moreover, the present invention 
may be embodied on a variety of different platforms, includ- 
ing Macintosh. UNIX. NextStep. and the like. Therefore, the 
description of the exemplary embodiments which follows is 
for purposes of illustration and not limitation. 
System Hardware 

As shown in FIG. lA. tfie present invention may be 
embodied in a computer system sudi as the system 100. 
which comprises a central processor 101. a main nocmory 
102. an input/output controller 103. a keyboard 104. a 
pointing device 105 (e.g.. mouse, track ball, pen device, or 
the Like), a display device 106. and a mass storage 1#7 (e.g.. 
hard disk). Additional ii^t/output devices, sudi as a print- 
ing device 108. may be included in the system 100 as 
desired. As illustrated, the various coniponents of the system 
100 ccHnmunicote through a system bus 110 oi similar 
architecture. In a preferred embodiment, the computer sys- 
tem 100 includes an IBM-compatible personal computer, 
which is available from several vendors (including IBM of 
Armonk. N.Y.). 
System Software 

A. Ovoriew 

Illustrated in FIG. 1B> a computer software system 150 is 
provided for directing the operation of the computer system 
100. Software system 150. which is stored in system 
memory 102 and on disk memory 107, includes a kernel or 
operating system (OS) 1^ and a windows shell ISO. One or 
more application programs, such as application software 170 
or windows plication software 190, may be ''loaded** (Le.. 
transfen'ed from storage 107 into memory 102) for execu- 
tion by the system 100. 

System 150 includes a user interface (UI) 165. preferably 
a graphical user interface (GUI), for receiving user com- 
mands and data. These inputs, in turn, may t>e acted upon by 
die system 100 in accordance with instructions from oper- 
ating module 160. Windows 180. and/or application mod- 
ules 170. 190. The UI 165 also saves to display the results 
of an operation, whereupon the user may supply additional 
inputs or terminate the session. Although shown concq)tu- 
aily as a separate module, the UI is typically provided by 
Windows shell 180. operating under OS 160. In a prefaied 
embodiment. OS 160 is MS-DOS and Windows 180 is 
Micros<rft® Windows; both arc available from Miaosoft 
Corporation of Redmond, Wash. 

System 150 also includes a Con^nitcr-bascd Training 
(CBT) system 200 of the present invention for aiding users 
of the computer 100. As shown, the CBT system 200 
interfaces with the system 100 through Windows shell 180. 
as well as interfacing directly through OS 160. Before 
undertaking a dialled description of the construction and 
operation of the CBT system 200 itself, however, it is helpful 
to first examine the general mi^odology of UI 165 and the 
event-driven architecture driving its operation. 

B. Graphical User (Wmdowing) Interface As shown in 
FIG. IC. the system 100 typically presents UI 160 as a 
windowing interface or workspace 161. Window 161 is a 
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rectangular, graphical user interface (GUI) for display on 
screen 106; additional windowing elements may be dis- 
played in various sizes and formats (e.g.. tiled or cascaded), 
as desired. At the top of window 161 is a menu bar 170 with 

) a plurality of uscr-conimand choices, each of which may 
invoke additional submenus and software tools for use widi 
application objects. Window 161 includes a client area 180 
for di^laying and manipulating screen objects, such as 
graphic objea 181 and text objea 182. In essence, the client 

10 area is a workspace or viewport for the user to interact with 
data objects whidi reside within the computer system 100. 

Windowing interface 161 includes a screen cursor or 
pointer 185 for selecting and otherwise invoking screen 
objects of interest. In response to user movement signals 

15 from die pointing device 105. the cursor 185 floats (Lc.. 
freely moves) across the screen 106 to a desired screen 
location. During or after cursor movement, the user may 
generate user-event signals (e.g.. mouse button "clicks'* and 
*'drags**) for selecting and manipulating objects, as is known 

20 in the art For example, window 161 may be closed, resized, 
or scrolled by ^'clicking on** (selecting) screen components 
172. 174^5. and 177/8. respectively. Keystroke equivalents, 
including keyboard accelerators or *^hot keys'*, are provided 
for performing these and other user operations through 

25 keyboard 104. 

C. Event-driven Architecture 

Underlying the windowing interface is a message or 
event-driven architecture. This nKxlel is pcihaps best 
described by contrasting its operation witti that of a modal 

30 or sequential architecture which has been traditionally 
employed. In this manner, the reader may appreciate the 
added flexibility of a message-driven system — flexibility 
which is employed by the CBT system of the present 
invention for providing bi-directional conamunication not 

35 only between the CBT system and a user but between the 
CBT system and a target application as well. 

As ^own in FIG. 2, a modal program 200 comprises a 
series of discrete operating blocks or modes 210. with a 
well-defined beginning, middle and end. In actual operation, 

40 such a program typically displays a scries of input screens 
for receiving user information, for exanq>le, to create a 
written repoxt. For instance, the first entry screen may 
require a customs name, the second a customer address, the 
third a part number, and so on. The program typically 

45 terminates in an output mode, for reporting results deter- 
mined from the various inputs. Thus, the program 200 
follows a fairty rigid sequence of operation, with each input 
or entry mode demanding successful con^)letion before the 
program proceeds to the next step. 

50 While a modal program is relatively easy to design and 
implement, it is not so easy to use. The design certainly 
ensures that all required information is entered, but only at 
the expense of forcing users to operation in a manner 
dictated by the progranL SpedficaUy, since the program is 

55 built around a prc-airanged set of modes, a user cannot get 
from one mode to another without hrst completing a 
previously-required mode. In the present example, for 
instance, a user must needlessly complete a customer name 
entry screen (and any other intervening input saeens) just to 

60 access part number information. Any deviation from this 
sequence by the user is simply not permitted. Lacking 
flexibility, modal programs make a poor choice for handling 
real-worid tasks. 

As shown in the second half of FIG. 2. an event-driven 

65 architecture 250 eschews a pre-selected sequence, opting 
instead for an "event loop." The event loop 260 is a 
centralized mechanism for processing messages about user 
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and system evcDis. B includes an event queue 270 and by placing it in the application queue. Control returns 

mecbanisnis for retrieving 263 and dispatching 269 mcs- immediately to the calling application, and any action to be 

sages to various window classes 280. Before each of these carried out as a result of the message docs no( occur until the 

oompoDcots is described in detail, it is helpful to have a firm message is read from the queue. 

understanding of "messages." 5 Ths ScndMcssagc function, on the other hand, directs 

In a typical modal environment, e^dally those typified windows to send a message directly to the given Windows 

by a character-based Ut a program reads from the keyboard f „ Qctioo. thereby bypassing the iqjplication queue. Windows 

by making an explicit call to a function, such as the C control to the calling application until the 

fimcUon gctchar ( J. The function typically waits until the windows function that receives the message has processed 

user presses a key before returning the character code to tfie unoucucd message, however, is generally a 

program; aU system acUvity ceases untU complcuon of this ^-^^^ 

oiie step, ID a Windows enviromnent m ^^"^f -^^^^^j^; TV general mechanism for retrieving and dispatching 

aUDg system uses niessages to manage and synchrom^ ^ event-based system, such as Miaosoft 

mult4)leapphcauoBsand todwa^ ^ ^^^^^ ^ 

a mouse or presses of a keyboard, which are converted to . ..i. . o ^nJ *- \^ .^^n^^^ iooa 

messages by Windows event handlers. ^5 gramming Windaws. Second EdiUoo. Microsoft Prcss^l 990. 

From a programming perspective, a message is simply a AddiUonal mformaUon can be found m Miaosoft s Window 

data structure containing infonnaUon about a particular Software Development Kit. including: 1) Guide to 

event. In Microsoft Windows, a message is a 16-bit unsigned Programming. 2) Reference, Vols. 1 and 2. and 3) TooU. aU 

integer which serves as a symbolic consUnt for a particular available from Microsoft Corp. of Redmond. Wash. The 

event; packaged within this integer is a message identifier 20 disclosures of each of the fwegoing are hereby mcorporatcd 

and message parameters, which vary with each event type by reference, 

represented. For example, messages from a window object First enobodiment 

might include informaUon about creating (WM_CREATE), Computer-based Training system 

closing (WM_CLOSE). moving (WM_>10VE), and lesiz- The foUowing descripUon of the CBT system of the 
ing (WM_SIZE) the window. The input messages are 25 jM-csent invention wiU focus on the presently preferred 
collected in a system-wide queue and then directed to the embodiment which includes con^x)neDts implemented in an 
proper window. These messages, along with timer and event-driven architecture with the C++ programming lan- 
screcn paint messages, must be passed to the target guage. In particular, an object-oriented model is adapted 
4)pUcation(s) of interest whereby new objects may be created from existing objects 
A mechanism is provided for retrieving messages from 30 (classes). The general features of C++, including data 
the system queue and dispatching them to the appropriate encapsulation, inheritance, and polymorphism, as well as 
iqjpUcation which, in turn, may proceed to process any C++ techniques for in^>lenienting class hierarchies and dass 
message that arrives. Each window belongs to a certain methods are known; see c.g., Ellis. M. and Stroustnip, B.. 
window type whidi defines certain characteristics common The Annotaud C++ Reference Manual, Addison-Wesicy. 
to aU windows of that type. Associated with each type is a 35 Additional information about object-oriented pro- 
Windows funcUon which processes all messages sent to gramming and C++ in particular can be found in Borlands 
windows of its type. An application queue is provided where C++3. 1: 1) User's Guide, 2) Programmer's Guide, and 3) 
Wmdows may place messages that belong to a specific Library Reference, all available from Borland International 
^Ucation. When the ^Ucation is ready to receive input, of Scotis Valley. Calif, The disclosures of each of the 
it simply reads the awaiting messages. If none are found or 40 foregoing are hereby incorporated by reference, 
if there exists a message for other ^^lications with higher A. Overview 

priority. Windows passes control to the other appUcations. Referring now to HG. 3, a Conqniter-based Training 

The message or event loop 260 shown in FIG. 2, for system 300 of the present invention includes one <x naore 

example, may be simply coded as: Application Translation Units (ATUs) 340, a Message 

45 Engine 350. and a S€rq>t Engine 330. Also shown, the 

system 300 includes a CBT window object 370 opcrably 

whife (GetMessa^e {&niBg, NUIL, 0, 0)) coupled to the Script Engine: CBT window object 370, in 

^ turn, may be linked to one or more custom Dynamic Link 

DUpiuchMcttage (&msa) ; Libraries (DLLS) 3«0. 

> 50 Driven by a set of instructions or script 320. the system 

tetum msg.wpBfam ; 300 mooitoTs various events of the Windows system and 

) • desired target applications. Messages from these events. 

" including system messages 310 and target application 

where a message (&msg) is retrieved by a call to GctMes- messages, are crapped by the ATUs 340 and reported to the 

sage (step 263); if needed, the retrieved message may be 55 Message Engine 350 as CBT naessagcs. The Message 

translated by a call to TVanslatcMessage( ) and then dis- Engine, in turn, dispatches the messages according to han- 

patched by a call to DispatchMessagc (st^ 269). This dlers specified by die Script Engine 330, operating under the 

*Vhile** loop continues until the GctMes sage function control of script 320. Messages of interest are processed as 

returns a value (rf zero — indicating that die loop has read a desired; others arc simply allowed to pass through. The 

WM_QUTT message from the queue, telling the a]^lication 60 construction and operation of these components will now be 

to end (yes at step 265). described in further detail. 

In addition to the messages generated by Windows, appU- 1. Application 'IVanslation Units and their Target Applica- 

catioDS can create their own messages and place them in the tions 

plication queues of other applications. The ScndMessagc [n normal operation of the system 100. a user is using one 

and PostMessage functions let applications pass messages to 63 or more Windows application programs, for exanqile. pro- 

their windows or to the windows of other applications: The grams 145 of FIG. IB. which can be a spreadsheet, 

PostMessage function directs Windows to post the message wordprocessor. database, or the like. For each application 
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where CBT suppon is desired, ao aj^Ucatioo-specific ATU 
340 is provided for processing eveacs specific to that appli- 
cation (now shown as target appUcatioo 360 in FIG. 3). 
Thus, each ATU 340 is a module, preferably implemented as 
a Dyoamic Link Library (DLL), for processing messages for 
a specific target application. 

In addition to the appUcalion-specific DLLs. ATUs 340 
include a Windows XSV. In contrast to the other ATUs 
}Mch hook into specific target ^plications, the Windows 
ATU processes all Windows events, including system mes- 
sages 310. In this manner, general system events, that is. 
ones not specific to any particular application, may be 
processed by the CBT system 300 as well. 

Whether application specific or not. each ATU functions 
to trap events and convert them into '*CBT messages** — a 
lingua franca or common language for all events, whether 
Windows or appUcation-spccific. oocuning widiin the sys- 
tcHL More particularly, a CBT message is a meta-message. 
that is. a high-level message dcscnbing one or more events 
which have occurred For iostance, instead of monitoring 
numerous, low-level system messages, such as 
WM_RBUTTONDOWN, WM_LBUTTONDOWN, 
WM_J^inTONUR WM_JLBinTONUR and the like, 
the user/script writer need only monitor a single message 
CBT_M0USECLIC1C; the task of determining what the 
Windows system or application is doing is left to the ATUs. 
By abstracting low-level system messages into high-level 
(and more meaningful) CBT messages, the system of the 
present invention greatly simplifies script design and writ- 
ing. 

A CBTT message, which is stored internally as an integer, 
represents a particular type of event Information or data 
particular to each event, such as active window, cursor 
location, and the like, on the other hand, arc packaged as a 
discreet data object (Eventlnfo object) fully describing the 
event. Eventlnfo objects, along with CBT messages, arc 
dispatched from the ATU to the Message Engine 350 for 
fiinher processing. 
2. Message Engine and Scripts 

The Message Engine 350 determines which of the many 
CBT messages it receives is erf particular interest to the CBT 
system, as it operates under the direction of a script 320. At 
startup, each target application of interest to the script 320 is 
registered with the Message Engine. The 5crq)t 320. which 
itself includes a collection of objects, may be compiled, 
pre-compiled, pscudocompUed,.or the like, as desired for a 
particular platform. In a preferred embodiment, script 320 is 
prc-tokcnized, whereby source listings and comments 
(optionally) are stored in a compact form which may be 
reconstructed into the original source. Thus, scr^ 320 need 
only be a set of instructions; no particular format is required 
by the present invention. 

For each application registered, the Message Engine 
maintains (me or more "handlers^ or modules for processing 
events specific to that application (as represented by the 
CBT messages). Thus, the Message Engine manages a list of 
target handlers for determining which C!BT messages arc of 
interest to the script 320. that is. which messages map into 
the list. 

Messages \siiich are of interest to the system. Lc.. those 
specified by the scrq>t 320, arc trap^d and forwarded to a 
designated handler. Tliose messages which are not of interest 
arc allowed to *tall through" (Le„ be passed on to) the 
individual target applications 360. In essence, the Message 
Engine filters the events for a particular application so that 
only those of interest, that is. those having a handler defined 
for the event, are processed. 



10 

B. System operation 
1. Method: CBT session 

Referring now to FIGS. 4A-B, the general method of 
operation for the system 300 is illustrated by a flowchart 
$ 400. While the general nrtethodology remains the same from 
one CBT session to another, the reader should understand 
that the specific steps of any one CBT session are dictated 
by instructions and script objects defined in the script 32t. 
For instance, the script 320 states which specific target 
0 applications will be registered with the Message Engine and 
which events of those applications will be dispatched. Thus, 
the following description illustrates the basic framewcH-k in 
which the CBT system equates. 
Under the direction of the script 320. at step 410 the CBT 
5 system registers a target plication of interest by creating a 
CBTApplicatioo object Serving as ^e main entry point for 
the CBT system, this object initializes and executes the 
script tutorial. Moreover, the object initiates sessions with 
the Message Engine and Script Engine and acts as a cen- 
a tralized dispatch point for all external functions and object 
method calls within each CBT lesson. From here individual 
CBT lessons are loaded and performed. 

When a lesson script is loaded the CBTApplicatlon object 
creates a CBTLesson object which is responsible for man- 
5 aging that particular lesson. The CBTLesson objea reads the 
lesson script and builds a deck of CBTSccne objects, with 
each c<XTcsponding to a scene described in the lesson scripi. 
Alternatively, each scene may be constructed on-the-fly. 
particularly in high-performance environments. The CBT- 
0 Lesson object resembles a state machine; it maintains the 
active scene (active state) and sends appropriate script 
scenes (CBTScenc objects) to the Script Engine 330 for 
presentation. Each object is dirccdy accessible to the script 
writer through script variables; fix example, the CBTAppU- 
5 cation object is accessed through a theCBTApp global 
variable, the CBTLesson object through a theCBTLcssoo 
global variable. 

To complete the initialization of step 410. die target . 
application is registered with the Message Engine 350. In 
0 particular, hooks are installed by a corresponding ATU 340 
so that events within the target application of interest are 
trapped. As set forth below, these events will, in turn, be 
reported to the Message Engine 350 as CBT tiKssages. 
At step 420, script-specified links arc established to 
5 individual resources of interest. Within the target application 
itself, various resources (e.g., buttons, menus, and the like) 
may be of Interest to the script writer. For exanople, if one 
were interested in a particular button of the target 
application, such as a "help** button, that button may be 
0 registered with the Message Engine 350. Events associated 
with that button (e.g., '^use enter" the button) are then 
trapped for processing by an ATU. 

The links are specified within ihe CBT scr^ 320 as 
follows. In a pseferred embodiment a link Is established to 
s an individual resource or control by indicating a selected one 
of its Endows class name. Window title, or Resource ID. all 
of which are readily accessible Windows data structives. 
Conunonly. a link will be established by using the Resource 
ID. Particular links may be created or removed during a 
0 session, as desired. 

At step 430. the system traps various events which arc 
relevant to the established links. This operation, shown in 
further detail in FIG. 4B. occurs as fallows. Every time that 
a message arrives at the message queue of a target 
5 aj^lication. a message filter hook function (WH_MsgFiltcr) 
431 is called. First, the hook function determines if the 
message represents a task which has been "^hooked.*" that is. 
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a specific link for this event of the target application has been 
created. If not. the event is passed down the hook chain for 
processing by one of the other hooks (Lc.. hooks 433. 435. 
437). The Windows hook 437. for exan^)le, traps ail window 
messages (WM_). In this fashion, whidi hook function is 
invoked depends on what type of message comes into the 
taiget application. By way of illustration, hooks may be 
installed as follows: 



BOOL ittstallHook5(CbtEiitiy •pEnttry) 
{ 

if ( ! pEctiy ) 
retuni FALSE; 

// Note thai the fourth panmeter bckyw may receive a task tandk 
// of a taiset applicatkxi, wbereupoa the book ts installed in that 
// appticatioa. Wbca receiviDg a NULL parameter, the book 
// mstalh to appbcatiam. 

// CBT hook ~ allow CBT system to stop «vetits from progressbs 
bCBTHook = 

SetWokkwiHook£x<WIL-CBT. CHOOKI>ROC)cbtFiber, 
hlnstance, NULL): 
// K^g filter book - diatoji boxes and inenus 
bMflgHook = 

SctWindowsHookEi(WH_MSGFILTER, (HOOKPROOmsg- 
Filter, hrn<»nrf| NULL); 

// Get msg hook 
bCjetMssHoQk = 

SetWtD(fcWGHook£x(WH.aElMESSAGE, (HO0KPR0C)get- 
msgFUter, Unstaiice, NULL> 

// WtxKkws book 
bCalIWDdPiocHook = 

SelWii>(k7wrflookEi(WH_CALLWNDPROC, (HOOKPROC> 

caUWndPiocFilier, hTnsianor, NULL); 
retun^ bCBTHook Sl& hMsgHooi && 

bCaUWoIPtocHook && bOetMsgHook ); 

} 



As shown, a callback function is installed for each hook; 
each callback function, in turn, serves as an entry point Into 
an ATU. Additional infoimation on the installation and use 
of hooks in Microsoft Windows can be found in die 
Microsoft windows Software Development Kit referenced 
above. 

In addition to installing hooks to trap system messages, 
one or more application- spediic hooks (callback functions) 
439 are installed as well. For instance, a target plication 
may be a spreadsheet which includes its own internal set of 
messages, for example. SS_CELLSELECT, 
SS_CELLEDrr. SSJLOCKDEFINE. and the like. To 
monitor these messages, an ATU may register an 
application- specific callback function with the target 
application, in effect dynamically binding the ATU to its 
target application. At runtime, the application invokes the 
callback function for dispatching internal or appUcation- 
q)ecilic messages. Thus, the CBT system of die present 
invention is not limited to Windows events and their mes- 
sages; instead, the CBT system may receive and translate 
any messages of interest whether system-wide or strictly 
intonal. 

At step 440. events which are trapped by the AppUcation 
Ttanslation Units 340 are **dispatched^ to the Message 
Engine 350 as CBT message/event information objects. As 
shown in particular detail in FIG. 4B. the dispatch module 
of each ATU includes a function corresponding to each 
Windows event. Thus, for the WM_COMMAND. 
WM_MENUSELECT. WM_BUTTONDOWN. and 
WM_SETCURSOR messages, the following translate 
functions may be defined: 



12 



utf doWM^Commaud (CbtEnliy •pEntiy, MSG •msg); 

ml doWM_Me&uSe]oct (CbtEntry *^ntiy, MSG *insg): 

im doWM^uttooDcwQ (CbiBntry *(£ntry, MSG *msg): 

5 nri doWM-_SetCursor (Cbt&itry •pEnlry, MSG •vasg); 



each designed for processing its particular evenL 

The operation of an ATU dispatcher will be demonstrated 
by the processing of Windows messages for determining if 
the cursor has traversed a window boundary (i.e., entered a 
new window); this exan^le illustrates how a multitude of 
Windows WM_SErCURSOR mess ages c an be converted 
into MOUSELEAVE and MOUSEENTER mcta-messages. 
The dispatching of other events as CBT messages is set forth 

13 herelnbeJow as Appendbi A. 

As shown in FIG. 5A. a doWM^ctCursor dispatch 
method 500 is invoked whenever a SetCursor message is 
trapped by the ATU (i.e.. captured by a hook function before 
the event has been received by the application). Here, the 

20 script writer is not interested in the screen cursor singly 
entering an already active window; thus, the method sinq>ly 
*'allows" the Windows message to be passed to the target 
application at step 501 tnd returns. Specifically, since the 
screen cursor is entering a window which is already active, 
no particular CBT-gcnerated message or other intervention 

^ is desired by the script writer at this point; hence, the 
WM_SETCURSOR message is allowed to pass dirougji. 

Continuing the example, the script writer may specify that 
the event of a cunor leaving an active window is of interest 
and should be trapped. Since the cursor is not simply 

3^ re-entering the active window (no at step 501), the window 
whidi the cursor is leaving should be notified of the event 
The CBT system notifies the Message Engine of this action 
as follows. First, at step 502. the informatioo pertaining to 
the window where the event occurred is encapsulated into a 

55 C-H- object (which is derived from an Eventlnfo dass 
hierarchy, described in further detail bereinbclow). At step 
503, the information object aod a *'MouseLeave" message 
are dispatched to the previous (departing from) window, 
with the message being denoted as a **NOmiV message. 

40 In a preferred embodiment two different classes of mes- 
sages are provided: CBT^KOTIFY and CBT_CONFIRM. 
Those messages which arc purdy infonnationaL such as 
mouse movements, are CBT^NOTIFV messages. Those 
which can be stopped before they reach the target 

43 application, on the other hand, arc called CBT_CONFIRM 
messages. Each is registered with Windows as an 
application-specific Windows event Using two methods 
defined within Eventlnfo objects, the script 320 can allow or 
prevent a CBT_C0NF1RM type message from reaching the 

50 target plication. Specifically, a stopMessage method is 
invoked which determines (based on script instructions) 
whether to allow the message to pass through to the target 
api^cation. 

After step 503. the nn^od proceeds to alert the Message 
55 Engine that the cursor is entering a new window. In a manner 
similar to sending the ^'MouseLeave'* ntessage. the method 
first builds an Eventlnfo object at step 504. Next, a "Mou- 
seEnter" message of type CBT_NOmFY is dispatched to 
the application, along with the information for Che event 
60 (Eventlnfo object), at step 565. At step 506. an active 
window flag is set; this is the flag tiiat is read in step 501 to 
determine if the mouse cursor is entering tiie active window. 
Finally, the method concludes by passing &e message on to 
the application (i.e., "allow" message) at step 507. At the 
65 conclusion of the method, memory for the Eventlnfo objects 
may be recovered (e.g.. using manual or automatic garbage 
collection techniques). 
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For purposes of Illustration, one may implement sudi a 
method in the C++ programmiog language as follows: 



void CALLBACK MnM^grKngiDe::DispgichCBTMcsgage(HTASK 
hTaisct, UINT cbtmsg, 
WPARAM wParam, LPARAM 



inl doWM_SetCursor(Cb(Eotry •pEctry, MSG •ms«) 5 IParam^ 

i I 

Ev«Uiifo»pObject = (EvemInfo'Tjf^ /; iait Evcntlnfo CbtSessitm •pSessk)n = GetS«sk«FiDmTi5k(hT«8«^^ 

if( pEiitry-thActiveWiid = (HWNDXmsg-^wPanm) ) // steps pSesskm ) 

return MSG_^LLOW; SKVSO? ScndMe»«c(pScssioo-»hMMPaDc, CbtMessagesicbtm»sl, 

pObjcct = Qcw Wwdowim i£ntiy-»hActivcWod ); // step 502 ^^ePi^LPmm)-^^ 

DispatchlbCbc(pEniry,CBT^O'nFY, // Notify applicatk» handkr 

TM^OUSELEAVE, // stq> 503 // wbe« pSe««x> b tt* cunrm ^Ikatwn 6«sioo 

(LPARAM)pObject); (detemincd fiom hTaigct); 

pObjeci = new VmdowIafoC (HWNDKm^-^wPamn) ): // step 504 „ CbtMessMeslcbtmsfll U tbe Ubk Joofcup for the 

DispatchToCbt(pEiiiry, CBT_J4anF% fj ^ ^^^^^ rconfinn" or "notify-; 

m_MOUSEENTER, // step 503 // wPannn is tl» CBT message type CrM_inss); aal 

(LPARAM)pOb>ect): fj ]nzxvm is a poimer to the Eventlnfo object 

iCntry-^hActiveWnd = (HWNDXois^-^wPanun); // step 506 " ^ 

return MSO^ALLOW; // step 507 

// gaiba^e coUection petfonned by the system 

) 



With particular reference to flG. 4B. this process is 
illustrated Message Engine Alters CBT messages dirough a 
Here, pEntry is a pointer to a record, CbtEntry. which is ^ plurality of message handlers, including, for example, a 
updated. The record includes handles to the hooked task TargetApplication handler 451. a TaigctWindow handler 
(application that has been hooked) and the cuircntly active 453. a Custom handler 455. and a Default handler 457; other 
window exemplary handlers are set forth herelnbelow as Appendix 

— — ^— ^— CBT messages of interest will be passed to a particular 

'^^^w^^^mS^L; handler. As shown in Appendix B, each message belongs to 

HWND hAftiveWDd; ^ particular Message Handler Qass and is either informa- 

> CbtEmiy; // pEntry points to diia tional (CBT _J^(jnFV) or preventable (CBT_CONFIRM), 

30 A **mouseEnter^ message, for example, belongs to a Tar- 
. . ^ • * • •* A * gctWindow Handler Class; the message is therefore pro- 

As shown, a mcta-message may inaintain Us da^ TargetWindow handier 553. An applioZ 

struoures for tracking events at a higher level (e.g., the ^^^^^^.^ ,3 ^ sS.EDrrCELL message &om a 
status of the acuvc window). spreadsheet target application, on die other hand, would 

The DispatchToCbt function, on the other hand, is con- 35 typically be passed to the TargetAj^licaiion handler 451. 
venienlly viewed as two halves of a process. Specifically, the Finally, messages without a handler, that is, those which the 
Message Engine registers a callback function wldi the ATU. scnpt writer has no particular interest, may be passed to a 
The operation proceeds as follows. On the ATU side, the default handler (e.g.. for ignoring, discarding, or otherwise 
ATU passes to the DispatchCBTMessage method a task invoking a desired default action); thus, the script writer 
handle for identifying a particular application; since the ^ need only enumerate handler methods for messages of 
system processes multiple applications, this mechanism interest. 

serves to distinguish between different applications (and If matched with a handler, the message is then dispatched. 

their instances): Specifically, the handler extracts propeitics for the message 

45 and the accompanying Eventlnfo object For a message of 

TargetWindow handler class, for instance, available object 

wpJxTlSram Oten.) properties include: 

^ -r, _^ TV- t.T^ X 1) Name: Title siring of the control; 
u( pCbiDiqiatcnFuzic ) 

(pCbiDi^tchFujKXhHookedl^ Msf, wParam, IPaiam); ^ 2) Class: Windows class of the control; 

2 3) ID: Resource ID of die control; 

4) Style: Style flags of the control; 

In this manner, an ATU filters or groups events by target 5) Enable: Whether the control is enabled; 

plication and communicates its events as tneta-messages 5) Posidon: Coordinates of the control; and 

to other CBT con^nents. At the completion of step 440 <rf 7^ Eventlnfo: Cuixent Eventlnfo object, if any. 

HG.4A theiJTUhasdispatrhedthcCBTmessag^^^ Additional exemplary properties whidi are avaUable for 

and the Eventlnfo object to the Message Engine 35#. thereby ^^^^ messages handler classes are set forth hcrcinbelow 

fully communicaling an event which it has trapped. Appendix C. 

Not aU events arc of interest, however. Thus, the events ^ ^ alternative to defining several event handlers, a 

should be filtered so that only those of interest are acted j^^^ prcfarcd embodiment provides only two basic event 

upon. At step 450. the Message Engine performs this task by handlas; an Application T inir handler and a Window Link 

comparing the CBT message against known event handlers. handla. Each is an object having various handler methods 

In other words, the engine attempts to dispatch CBT mes- for appropriately responding to each message passed. Based 

sages of interest — ones having a handler define for the event 65 on the lookup performed by the Message Engine (i.e.. 

Thus on die Message Engine side, the Message Engine NOTIFY or CONFIRM), an Application Link handler may. 

deteimiDcs which entry in its table corresponds to that task: for example, effect the dispatching as follows: 
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RESULT CALLBACK AppUcatioaLink:wQdPioc(HWND hamd, UINT 

Mcs»£c, WPARAM 
wParam, LPARAM 
IPanm) 

{ 

// First, get bandki (torn Imk re^terBd) 

Appl^BtkmLink *pWiodow « (ApplicationLink *)GctWind(rvLoi^- 
(bWaL 0); 
if( pWindow ) 

iff Messa^ = CBT_nDtify ) // Msg b a NOTIFY wsg 
{ 

EvenOiifD *pIafo = (Evmtliifo *)!Paiam: 

// RecaU thai Evexil info inclodes ooe or mm of a win 

// chu, name, and icsource Q>. U exact infonnatioo is cot 

// piwided (e^^ jusi "OK" bunoo), do "fuzzy" matcb 

// (ix., asUch as much as possible: 

pWuidDw-Hk)DispatchNotify(wpann. pinfo); 

Plafo->Fmisbed( ); 

le turn TRUE; 

\ 

eUe tf( Message = C6T coafiim // Msg is a CONFIRM msg 
i 

Eventlnfo *plnib = (EventlnJb *)lPaiam; // Event infb 
pWtDdow->doI>tspatcbCoofiini(WPuBm, ptnfo); 
(dnfo— ^Fuiisfaed( ): 
return TRUE; 
} 

\ 

// oo lecum, call WtuProc instanfialed w/ ^tic. link 
return I>efWindawProc(hWnd, Message, wpanm, IParam); 



Here, the doDispatch- methods communicate directly with 
the Saipt Engine. In turn, the Scr^t Engiae re^nds 
according to script objects defined within the active script 
By invoicing the stopMessage method for specifying 
whether an event is allowed, for exatnple. events may be 
stopped from reaching a target Explication; in most 
instances, however, die script writer will simply specify the 
default — diat the event should simply pass on through to the 
target application. 

The script writer may provide methods for handling the 
various events of interest, or be or she may rely on d^ault 
methods which arc defined by the CBT systcnL In operation, 
a CBT message is passed to the objects. Each object, in turn, 
is responsible (through its method deiimtions) for knowing 
which messages are of interest, and how each one of Interest 
should be processed. In a target application, for example, if 
the script writer hooks a window link up to a list box of the 
application, he or she should provide methods for handling 
the event (as commimicated by CBT messages) of that list 
box. 

Refeiring now to HG. 5B. the overall method of dis- 
patching messages is suixunarized. In a doDISPATCH 
method 520 of tbe fvesent invention, a CBT message arrives 
at the Message Engine and is processed as follows. First in 
step 521. an attempt is made to match the message to an 
q)plication link handler. If the attempt is unsuccessful (no at 
step 522). then the message is simply allowed to **fall 
through** (i.e.. left unprocessed, or processed by a d^ault 
handler), otherwise (yes at step 522). at step 5^ the Mes- 
sage Engine forwards the CBT message (with Eventlnfo 
object) to the identified Application Link handier. 

At step 524. the Application link handler examines die 
Eventlnfo object and aaempts to match it with a registered 
window link. If this step is unsuccessful (no at step 525). 
theo a Default handler will be assigned for processing the 
event at step 526. At step 527. the message is forwarded to 
the Window Link handler. The Window Link handler, in 
turn, dispatches the message to the Script Engine at step 528. 
At this point, the Script Engine identifies the event by 
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mapping the message into its set of known reserved words. 
At step 529. the Script Engine processes the message 
according to the instructions of the script (i.e.. effects die 
action desired by the script writer, as indicated by the use of 
5 the matching reserve word). Upon completion of this step, 
the method has successfully dispatched the meta-messagc. 
widi appropriate actions being effected in response to that 
message. 

2. Building CBT Lessons 

10 As a tutorial is designed, the CBT script writer creates a 
''stoiyboard" showing the visual appearance as well as the 
flow of die tutorial. The storyboard becomes the basis for the 
CBT lesson script 

CBT scripts are written in a simple language which 

15 contains both message handling and object-oriented fea- 
tures. Each lesson scrq>t is organized as a collection of 
scenes, with each scene describing the actions that take place 
at a particular point in the lesson. For exan4>le. a scene 
might instruct the CBT system to display a window con- 

20 taining some text when a particular menu item is chosen in 
the target application. As the lesson script proceeds, new 
scenes can be perfomed. This process continues until the 
user diooses to exit the CBT or the lesson is finished. 
To control the target application, the CBT system inter- 

25 cepts all Windows events for the application and translates 
them into CBT messages. These messages will trigger any 
corresponding message handlers which are defined within a 
scene. When a message handler is triggered, its scrq>t is 
executed. 

30 Within each scene, message handlers arc defined for each 
UI control in the apj^catton which is of interest. For 
example, to re^nd to a button dick within the script the 
following handler is defined: 

35 — — — ^— — — — — 

script for Scenel 

TaigetButtDO dvButtonC 1 20) 
Qo thcButtoii.buttoflClick 

theCBTljessaQ.peifomiCSceiieZ") 

end 



This hypothetical scene creates a T^getButton object which 
is linked to the UI control in the target plication; the UI 
control Resource ID is 120. Next, a Message Handler is 
45 defined for the buttonclick message from the TargctButton 
object. When this message is received, the Script Engine 
performs a new scene. Scene!. Thus, the statement: 

the CBTLessoa.perfixinCScexie2") 

50 calls the perform method of the global object **theCBTLcs- 
son" (the CBT Lesson object). 

In addition to controlling user actions, the CBT lesson 
also drives the target application autonomously by sending 
appropriate messages. Alternatively a sequence of events 

55 can be recorded (eg., using a tool similar to MS-Windows 
Rcca-der) for later replay. 

The script may also query the target ai^lication for its 
current properties. If a window link is established to a 
button, for instance, the script may query the button for its 

60 properties, such as its size, its title, and the like. One should 
DOtc that the ability to query for properties operates inde- 
pendently of the processing of events and their messages. As 
another example, a target q>plication could be asked to 
enumerate all the buttons of a dialog box. The script may. in 

65 turn, act on the queried information, including modifying 
selected resources. In this fashion, the resources of a target 
application may be dynamically varied, thereby providing 
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the target aj^catioo with an alternative user interface— one 
having UI conq>onents which may be altered on the fly. 

Appended herewith as Appendix D is a source listing 
illustrating an exenq>lary script syntax and nicthodoiogy for 
operating the CBT system of the present invention. Addi- 5 
tional reference materials illustrating a prefmed script syn- 
tax may be found in (siginaily-filed Appendix F. now 
canceled for convenience of patent publication, the disclo- 
sure of which is hereby incoiporated by refcrcncje. 

3. Multiple-application Lessons jq 
As shown by FIG. 3. the system of the present invention 

is operative with one or more applications 36#. More 
particularly, according to the present invention, a single 
script 320 may be employed to not only contrc^ mult^le 
af^lications concurrently, but also control interaction 
between multiple applications. A script may be provided for 
tutoring the user in the operation of cutting and pasting 
between applications, for instance, cutting text from a word 
processor and pasting it into a database applicatioa Thus, 
the CBT system 130 Is not application bound; instead, ^ 20 
a complete subsystem — one which may control multiple 
applications, including interactions between applications 
and/or the operating system, even launching additional 
q)plications as needed 

4. Event Information (Evcntlnfo) Objects 25 
An Eventlnfo object which stores information about a 

particular event, is instantiated from an Eventlnfo dass 550. 
FIG. SC illustrates the Evcntlnfo inheritance tree and lists 
the properties foEventlnfo class hierarchy c Eventlnfo class 
hierarchy 550 includes nine derived Evcntlnfo classes which jq 
contain the state information about the various standard 
CBT messages. At the root of the hierarchy is die Evcntlnfo 
base class 551. In a preferred embodiment, this class may be 
constructed with the following Oh- class definition: 

35 



class SHARED_CIASS Eveidliifo : pdrtic CbcObject. 

public |£veiilliifo { 

ATONriAfiLESCKeyward, 7) 

HWND hwndTKSct; 

BOOL bAUowMsg; 

BOOL bbProceasb^; 
public: 







Eventiafo(HWND bwod); 


virtual 




-Ev«iitliifo( >; 


virtual 


int 


Su[iFarts(hPn>tocol &Hdl) const; 


ioline 


HWND 


WindowHaodleC ) const; 


virtual 


const char * 


^^DdowNanicC ) const = 0; 


virtual 


const char • 


^i^MlowCIassC ) const = 0; 


virtual 


int 


WmdowJd( ) const = 0; 


virtual 


LONG 


WiDd>wStyk( ) const = 0; 


virtual 


BOOL 


ADowMes$age(BOOL UH^ BOOL bSUJe); 


virtual 


BOCH. 


I^ocessipgMsgC ) const; 


virtual 


void 


FmisbedO; 


znline 


void • 


operator De(w(un^gQed size); 






cpcntor delete(Toid 
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ATOMMETHODS (Keyword) 
CLASSMEIH0DS(EvMillnf6, *TVENTIKFO'0 
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As shown, the Evcntlnfo dass 551 provides access to the 
Windows name and its class, its resource ID. its Windows 
style, and whether the message is allowed (according to the 60 
script 320). 

Derived from Eventlnfo class 551 is Windowlnfo class 
552. a pure virtual base class for other Evcntlnfo classes. 
Hie subclass affords the same four pieces of information 
which were provided by the base class 551. In addition, for 65 
a given window handle, die object wUl extract a window 
name, class. ID. and style. The class may be constructed 



with the following C++ class definition: 



class SHAKED_CIASS WiDdowInfb : public Eventlnfo { 
protected 

int iWtodowld; 

LONG IWinlowStylc; 

char • sn-WindowName; 

char • strWittlflwClass: 
public: 

WindDwInfo(HWND hWod); 
virtual -Wiixtewbift)( ); 

virtual int Supports(hPiocacaJ AHdl) const; 

virtual const char • WindowNanic( ) const; 
virtual const char • WindowClass( ) const; 
TOiual int Wtndawld( ) consr. 

virtual LONO WindowStyk( ) const; 

CLASSMEraODS(WtafawInfo, "WINDOWINPO-) 



In addition to the windowing information, other events 
are also of interest particularly mouse and keyboard events. 
These other events are accessible through subclasses of 
Windowlnfo class 552. Specifically, the Windowlnfo class 
spawns five subclasses: WinHelpInfo class 561. WinPosi- 
tionlnfo class 50. WinShowInfo class 565. WinSelectlnfo 
class 567. and Keyboardlnfo class 569. As shown, objects 
may be instantiated ficom these subclasses for accessing help 
text, window position, menu information, keyboard events, 
and the like. WinHelpInfo. for instance, contains the text 
whidi was sent by the NWnHelp engine to the CBT. This text 
can be a sequence of script statements whidi are executed or 
simply a string of text WinPosition provides the coordinates 
of the window. WinShowInfo contains the SWP^flags cor- 
responding to the Windows ShowWindowo function. Win- 
Selectlnfo contains die name of the selected menu or control 
window item. Keyboardlnfo contains the key that was 
pressed as well as any flags indicating if the <ALT>, 
<SHIFr>, or <CnU-> keys were also pressed. 

l\vo classes. WinPositionlnfo class 563 and WinSelect- 
lnfo class 567. spawn additional subclasses. As shown. 
Mousclnfo class 571, which is derived from WinPosition- 
lnfo dass 563. provides direct access to mouse events; it 
contains the mouse button that was clicked and whether it 
was a single or double dick as well as Che position of the 
mouse. WinSelectlnfo dass 567, on the other hand, spawns 
Menulnfo dass 573 and Listlnfo class 575. The former 
provides access to. menu IDs and menu flags, the flags 
indicating whether the menu item is grayed, highlighted, or 
the like; the latter provides the index of the selected item, 
which is important if the list does not contain text 
Second embodiment 

Computer-aided Software Testing System 
A. Introduction 

An alternative embodiment of the present invention, one 
ad^ted for automated testing of GUI applications, will now 
be presented. Before discussing the constructicm and opera- 
tion of the computer-aided software testing embodiment in 
detail, it is helpful at the outset to tniefly review parameters 
for quantiiying the effectiveness of software testing. 

By automating the tasks of "controlling^ and '^observing** 
the target software, the burden of testing for the QA engineer 
is substantially reduced. In other words, the more success- 
fully the QA engineer can control and observe the software 
program, (he more effective the test becomes to automate. 
This can be restated as a formula: 

Test Autocnation E&ctiveQess=<3E<!ontioIlabil2ty>c%Observ&bi£ty 

where Controllability is a rough measure of how effectively 
the program can be automatically controlled into a given 



08/21/2003, EAST Version: 1.04.0000 



5.75 

19 

state, and Observability is the measure of how effectivdy a 
bug can be automaticalty observed when the program beiog 
tested is in a faulty state. Test AutomatioD Effectiveness is 
the product of these two factors for the program under 
examination. 

Consider, for example, Ihc task of testing a software 
compOer having both coimnand-lioe and GUI components 
(such as found in commerciaUy-availal^e con^ilers from 
Borland and Microsoft). Conceptually, testing the GUI por- 
tion of the compiler should be easier than testing the 
command-line portion, owing Co the latter *s complex inter- 
nal operations. In practice, however, it is far easier to test the 
command-line poftioo. The QA engineer need only develop 
test programs or data files that are run through the compiler 
using a simple batch file. Here, it is easy to achieve total 
control for the non-GUI portion. Observability is also high 
because return values or variables denoting the state of the 
compiler can be tested and written to a file using simple 
program statements that print the results. 

The task of automating the control of a GUI program, in 
contrast is particularly difficult Specifically, the task of 
maintaining pre-recorded input (i.e.. keyboard and mouse 
actions) and test scripts is not only very time consuming but 
also prone to error. If die degree of cootroUability and 
observability of the automated tests can be increased, the 
task of testing GUI software may be made easier. 

According to the present invention, the QA engineer 
constructs a high-level model of an plication's UI using 
prefabricated building blocks. This higji-level modd serves 
as a middle ground between test scripts and the ^>plication 
being tested. The knowledge of how a given UI element is 
controlled or how it can be observed is retained in the model 
rather than in a test script. Consequently, the test script 
consists of easy-Co-maintain, high-level testing commands 
only. Fot instance, an exemplary script fa: opening a par- 
ticular file (e.g.. 'testl-txt") may be defined as follows: 



HwApp J=Uebfecu.Open.Select( ) // Select Fik I Open menu 

// ActiveDialQg now tcpmacnta die Fife Opcsi dak>s 
ActiveI>talo«JJilename.SetnestLCir) // Type in tbe 6k name 
ActivcI>t«log.OKX:&ck( ) // Click on tile OK button 



One need only include high-level statements defining the 
(^ration, such as shown above. 
B. system overview 

Refcmng to FIG. 6. a software testing automation system 
660 of the present invention includes Generic Element 
Models (GEMs) library 61t. AppUcation-spccific Testing 
Models (ATMs) 615. Resource DaUbase 620, one or more 
Model Generators 625. Test Runtime Libraiy 630 (fa- 
storing Test Objects or Test FUoctioas. typically as one or 
more Dynamic Link Libraries (DLLs)), Script (inteipretCT) 
Engine 635. Message Engine with one or more Application 
TYanslation Units (ATUs) 640. and an in-memory Testing 
Model 655 (of the application under test), and one or more 
test scr^ 660. 

Communication directly with the application under test 
665 is effected through Windows API 670 and/or Test Port 
650. Using Windows API 670, various Windows messages 
may be sent or posted to the a{^cation for querying the 
Implication or effecting particular operations, as is known in 
the art. For instance, one may determine at runtime whether 
a checkbox screen object is checked (Le., toggled to its 
"Checked^* stated) by invoking the standard Windows API 
call: 

bDUBuRooChecked (bwndDlg, idButton) 
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where, hwndDIg is the handle of dialog box and idButton is 
the identifier of die button/checkbox. Documentation for the 
Windows API is provided in the Microsoft Windows Soft- 
ware Development Kit (SDK), available directly from 
Microsoft (aiid several other vendors). In addition to com- 
munication with the application under test 665 through Che 
Windows APL application- specific messages may be regis- 
tered with the Windows OS. as is known in the art Test port 
650 represents the use of such application specific messages 
for communicating with the application under test 665. 
' In general operation, the system employs the Model 
Generator 625 to decompose the application under test 665 
to generate the Application- specific Testing Models (ATMs) 
615. Each ATM is a high-level model for a ^ciftc com- 
ponent of the plication being tested, such as a File Open 

13 dialog. ATMs desmbe the actual component which they 
represent in terms of Generic Element Models (stored in 
GEMs Library 610), wlxich will now be introduced. 

A GEM encapsulates the behavior of irreducible user 
interface elements such as push buttons, checkboxes. 

20 listboxes, and the like. GEMs are instantiated when an ATM 
corresponding to an active state of the application under test 
is activated by the Model Manager 645. GEMs load Cheir 
expected results from ttie Resource Database 620 and are 
capable of binding themselves dynamically to the actual 

25 object on the screen whidi they represent Each GEM 
therefore can perform a "self tcsr on itself by simply 
comparing its expected result (as stored in the Resource 
Database 620) to its actual behavior (as displayed on the 
screen at runtime). In this manner, an entire application can 

30 peiformaself test by simply asking all its con^XMients to test 
themselves tn turn. 

Driven by a test script 660, the Testing Model 655 of the 
application under test 665 eix^loys both Windows APIs 670 
and/or the Test Port 650 to control the q;>pUcation being 

35 tested into various states; io each state, the results generated 
may be observed for error. The Model Manager 645 moni- 
tors the state of the ^>plication uiKler test using die Message 
Engine and Application Translation Units (ATUs) 640 
(components whids are the same as those described above 

40 for Che first embodiment). ATUs translate low-level mes- 
sages Into high-level messages, di^atdiing diose events that 
the Model Manager 645 has registered an interest in. Driven 
by the changes in ffie state of die application under test 665 
and/or events occuriiDg in the system, the Model Manager 

45 645 instnicts the Script Engine 635 to load and execute the 
appropriate ATM 615 which corresponds to the active state 
of the application under test. The test script 660 employs the 
Test Library 630 and die Testing Model of die Ai^lication 
655 to carry out the test execution tasL The construction and 

50 operation of the system components will now be described 
in detail 

C. Application- specific Testing Models 
Application-specific Testing Models (ATMs) provide 
high-level representation for specific components of the 

55 application under test. An ATM for a File Open dialog, for 
instance, describes the actual dialog in terms of the 
fundamental, pre-coostructed building blocks which it com- 
prises. In this manner, an entire application can be described 
using a library of ATMs. 

60 In a preferred embodiment at least five categories of 
ATMs are automatically provided by the system: Menus, 
ToolBars. Dialogs, Client Area Windows, and a Status Line. 
Each of tfiese categories corresponds to a base dass pre- 
supplied with the system Eadi base class encapsulates 

65 functionality associated with its category. A menu base dass, 
for instance, includes data members for describing menus 
and methods operative on those data members. The base 
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classes simplify the Model Ge aerator* s task of creating 
ATMs. Moreover, the base classes allow the QA engineer cr 
software developer to construct custom ATMs by simply 
deriving specific instances of the prc-suppUed base classes. 

Consider, for instance, an application having a File open s 
dialog. An ATM representing such a dialog may be aeated 
by derivlDg a FileOpenDlg class from the pre-existing base 
class for dialogs. The pre-supplied base class for dialogs 
("BaseDlg^ class) already encapsulates the behavior and 
propeities of a generic dialog box. Thus, the task of mod- lo 
eling a File Open dialog is greatly simplified. In a like 
manner, other aspects of the application may be modeled 
using the base classes whic^ are provided for the other 
categories. For instance, the application's menu and client 
area may be modeled using pre-si^^lied BaseMenu and 15 
BaseClicntArea classes, respedivdy. 

Before describing ATMs in fimfaer detail, it is helpful to 
review runtime construction of screen objects » such as 
dialog boxes in Microsoft Windows. Consider a typical 
dialog, such as confirmation message box dialog 700 showD 20 
in FIG. 7A. The dialog 700 comprises a screen window 705 
which includes a plurality of elements, inchiding caption bar 
710, static text 715. and buttons 720. 725, 730. Each of these 
''children** may. in turn, include stilJ further elements. Button 
720. for instance, includes a cation text or label: **Xes*'. 25 

FIG. 7B shows the resource or progracmning statements 
attendant to the creation of each element of dialog 700 (e.g.. 
in Microsoft Windows). The first line of resource file 750. 
for instance, defines a DIALOG screen element, named 
DIALOG_l (identifier), and includes screen coordinates 30 
(111. 98. 151. 59) specifying a starting location and size 
(ending location). The second line specifies various window 
attributes or '"window styles'* that the dialog 700 is to 
assume. Dialog 700. for instance, is to be a ^"popup** window 
(Microsoft window styleaWS_POPUP) with a cation bar 33 
(Microsoft window stylc=WS_CAPTION) and a system 
menu (Microsoft window style=WS_SYSMENU). A cap- 
tion statement (CIAPTION "Confirmation") specifics that the 
text **Confirmation" is to be displayed in the cation bar 710. 

Also shown in the resource script are the children screen 40 
elements of die dialog 700, Specifically, the static text 715 
is defined by the LTEXT staten^nt. while buttons 720. 725. 
730 are defined by PUSHBUTTON statements. The defini- 
tional statement for each of these includes infonnation 
similar to that of the parent dialog window — namely, a 45 
caption label, an idemifier (resource identifier), a starting 
location and size, and window styles. Button 710. for 
instance, is defined by a resource statement having a caption 
of "AYes*" (& tells Windows to underline the immediately 
following character), an identifier of 101. screen coordinates x 
of 24, 35. 24. 14. and window style of WS_CHILD (child 
window), WS_VISIBLE (visible), and WS_TABSTOP 
(tab stop for setting input focus to this element with tab key). 

The foregoing relationship between resource ( JIC) script 
files and screen objects is well known in the field of 55 
Endows programming. For those readers unfamiliar with 
these concq>ts (i.e., non-\Mndows programrDers). it is 
strongly suggested that the following references be con- 
sulted: Pctzold. C Programming Windows (particularly. 
Section IIL Using Resources); Borland C+f: Resource 60 
Workshop; and Miaosoft Windows Software Development 
Kit/Microsoft Visual C++. 

FIG. 7C illustrates that resource statements in a resource 
file are at runtime actually translated into Windows AFI 
calls. In particular, a given resource is created at runtime by 65 
calling Windows CrealcWindow function, with the afore- 
mentioned attributes passed to Windows as parameters. 



Create Window is a standard Windows API call (and is 
therefore fully documented in the Petzold and Microsoft 
materials, as well as numerous other references). The " 
Yxes* " button 720. for instance. Is created by the following 
CreateWindow call: 



CreateWiockw ( 



bifltoo. 

WS_CHn-D I 

WS_ VISIBLE 1 

WS_TABSTDP, 

24/cxChar*4, 

3ycyaiar*8. 

24^cxC2»ar*4, 

14/cyChar*8, 

NULL, 

fOILL 



// window ctass ouoe 
// wiDdow captkMi 
// window styk 



// initial x position 

// ioiziaJ y posicion 

// initial x size 

// initial y size 

// parenl window H^tvTV 

// window menu handle 

// piogruD insUDce bandk 

// creatioQ parameters 



At runtime, therefore, the Message Engine may trap each 
CreateWindow API call for determining each screen object 
which is about to be aeated. 

Using known techniques, the Model Generator 625 may 
dccon^>ose the resources of an api^ication to automatically 
construct a model specific for the application — the 
Application- specific Testing Model or ATM. Known tech- 
niques include reading Windows resource information. 
Since resources may change dynamically at runtime (e.g.. 
menu item becoming "grayed out"), it is more preferable to 
dynamically poll resources at runtime. Thus in a preferred 
embodiment, the resource information is learned 
dynamically — at the application's runtime — using Windows 
API (calls) 670. or Test Port 650 (in the instance of a 
pr<^etary control object). Exemplary calls are provided 
below (with reference to the Notq)ad example of FIGS. S 
and 9), Once the api^cation*s resources are learned, the 
Model Generator proceeds to construct each ATM by declar- 
ing the individual resources in a class definition derived 
from BaseDlg — tttt generic dialog class which encapsulates 
all the properties and functionality fouixl in an empty dialog 
box. 

In an exetr^lary embodiment, BascDlg may be con- 
structed from the following dass definition: 



// BsseDlg class rfefinitinn 

cbsG BaseD^C ) 

//Begin Constructor 

Moniker = 0 //Live Knk to the actual dialog oo the screco 
Id =0 //Unique id used as iodbx to Ceteli ei^ected 

//values for this dialpg frum the resource dbase 
entice =0 //Diakjg's expected cipdoQ 
pRrentNime 0 //Parent Window's Capctoo or Name 
S^le =0 //This dialog's siyte 

Dimensioo = 0 //Coortfinales and size 
Children » 0 //Reference to &c compnnmrs of this daaJog 
NumOtlCids = 0 //Number of componeiics m this dialog 
I^trcnlPtr = 0 //Refetcnce to application which owns this dialog 
//End ConstnKtor 

flincaoo Init( CI, Cap, App. Resid ) // CUsi, Caption. Application 
// refiereooe and Uniqiie Id 
//Establish a live link to the actual dialctg on (he screen 
//by instantiating a WindowPtoxy object called "Moniker'* 
WmdowPraxy Xfcnjker( " CI, Cap ) 
//Set ParemPtr and Id 
PareotPtr — App 
Id =Ka1d 

//Fetch expected values from the resource database 
//using the 'hT' key 

Defaihs.LoadPataf IX Capooo, ParentName. Style, 



08/21/2003, EAST Version: 1.04.0000 



5.790,117 



23 

-coDtinued 



DimcnMOO ) 

//Bind eacb compooem to che c a rre sp ooding clnucoi on ifac 

screen 

i=0 

while ( ( < NumOfKids ) 
Child ^ Chikbes] i 1 

Cfaikl£tn]( ) //Sec fiucGcm's BiodC ) membcT fuDctkn 
i = i + 1 

eod 

hmctioa DelacbChUdiec( ) 

//Detach from the acnol dialog on die screen 

i = 0 

whik ( i < NumOfKids ) 

Child = Chikkcnl i | 
ChiklDetachO 
i = i+ 1 

end 

Momker = 0 

cod 

function SelfTestC ) 

//Bist or Built-in-self-test coolrols verificatioo and log^ 
//messages to the apfxopriate file in a specified fbnnal 
Bist.Stait( -Dialog selftesr'. Id ) 

Biil.VerifyC "Captkm", Caption, Mooikcr.Captioo ) 
B'layenfyC^ajtcr, ParcntNamc, ParmtPlT.Mooikff.- 

Caption ) 

Bist.\feriiy( "Size", Dimcnsica, Moniker.OetSirc< ) ) 
Bist.VerifyC "Siyle", Style, Monikcr.GeiSiyle( ) ) 

B'isl.Vcnfy(*C}^k^^, NumOfKids, Moniker.GetNumOf- 

Kids()) 

//Instruct eacb oompODent of the dialog to test itcelf 
i=0 

while ( i < NumOfKids > 
Child = ChitdienI i ) 

ChiVd.Sclfrest( ) //Each Child has a SeifTestC ) 
//member function 

i= i+ 1 

end 

Bist£ndSection( ) 

end 

// Capture anributes of this dialog and its children 
fuDctsQD C^tan( ) 

// ... place bolder for custom code; insert as desired 

cai 

// Move wiolow X pixels bDrizontally and Y pixels vertically 
fiiactiooMovc<X, Y) 

/; ... place bokier for custom code; insert as desired 

eol 

// Size window X pixels bonzontaUy and Y pixels vertically by 
// stretching the bottonwisbt ooraer. 
fitoctioa Size( X, Y ) 

// ._ place bolder far custom code; inser as desired 

end 



end 
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As shown. BaseDlg includes a Moniker data member. 
Mooiker is a Live link to the actual (corresponding) object on 
the screen. The link is created by calling WindowProxy. a 
C-H- dass which encapsulates Windows iiif onnation for the 
object. In an exemplary embodiment, WindowProxy 
includes the following C-H- class constnictor: 



Windowpiaxy::WiiKiowPiQxy (const char *strTast. 

const char •cOrClatt, 
const char *stjTitk) 



i 



strWindowNiune = (char *)Dew cbar- 

|MAX_WINDOW_J^AME+l |; 

strWtodowCUss = (char *)oew cbar- 

pv^AX_WlNDOW_NAMB^-l |; 

strTaskName = (char *)Qew char- 

lMAX_WINDOW_J*AMB<-l j, 

•strWindowClaas = •strWndowName = •strTaskName = *W; 

iff soTaslc ) 

STRCPY(stiTafikName, strTask): 



bTargeOask = ge<TaskHand]e(EtiTask); 
bWodTarffct - RadWtix]ow(stiCiass, strTule); 
BindToWindovCbWDcfraiset): 

5 \ 

The cocBttKtor oxhides a call to a BincfroWinckTw method which may be 
constructed as follows: 

BOOL WindowPioxy::Bin(froWindow(HWND hWnd> 
{ 

BOOLbStanis; 
10 if( bWod && IsWindow(bWDd) ) 

\ 

GetWmdowText( hWod, strWindowName, 
MAX_WINDOW_NAME ): 
GetChssNacK ( bWnd, strWindowClass, 
MAX-_WINDOW_NAME ); 

iWindowW = OctWmdowW»d(hWnd. GWW_JD); 
IWindowStyle = Ge!WialowLocg(hWnd, CWL_STYLE); 
bWndTaigct = hWod; 
b Status = TRUE; 

) 

else 

20 istrWindowName = •strWiadowClass = V)'; 
iWincfewU = 0: 
IWindowStyle => X: 

hWodTaiget = (HWND>KinX; 

bStatus = FALSE: 

} 

25 bCuTThem = (HWND)NULL; 
letum bStitus; 



As shown, WindowProxy *s constructor encapsulates Win- 

^ dows handle, task handle, caption* and the like for the Object 
In the event that the object is not a Windows control (e.g., 
it is a s]^eadsheet or other implementation-specific object), 
the information may be nevertheless encapsulated (as shown 

J J by the above "else" clause of BincTToWindow). Other exem- 
plary method prototypes of WindowProxy arc set forth 
hereinbelow in Appendix E. 

Regardless of how it is implemented, the Moniker, once 
created, is an encapsulation of the actual object on the 

40 screen. The properties of the Moniker fully describe the 
corresponding object on the screen, thus giving a live link to 
the actual screen object The Resource Database, on the 
other hand, stores expected data f ot the object. The two may 
be con^)ared against each other (e.g., during SclfTest) for 

^ detecting nintime orors. as well as modeling problems. 
In addition to the Moniker, the BaseDlg class includes two 
other data members: Children — a reference to the compo- 
nents of the dialog, and NumOfKids — number of con^x>- 

5Q nents (kids) in the dialog. These are enq)loyed in the SelfTest 
method of BaseDlg. 



fuoctioo Selfrest( ) 

i = 0 // i&it to first kid 
55 whik ( i < NumOfKids ) 
f ^i^H = ChildnenI i ] 
ChikLSelfTcstf ) 
i= i + 1 

end 

end 



// test this kkl 

// tncremeal to next kid 



60 



As shown, this allows a dialog object to test itself by asking 
its children to. in turn, test themselves (by calling their self 
test methods-<3uld.Sclfrest( )). 
63 Moreover. SclfTest may include various levels of 
testing — each level denoting mtre extensive testing. For 
instance, maximum (all levels) testing may be performed by: 



08/21/2003, EAST Version: 1.04.0000 



5.790,117 



25 



functkm Seinest( MazLevds ) 
i =0 

iLcvel = 0 

wbOe ( iLevel < MaxLeveU ) // step throa^h all levcb 3 
whik( t<NuiiiOfKids ) 
Child = Cfaildnml i | 
Cluk!.Sclfrest( iLcvel ) 
i = i + I 

end 

iLcvcl iLevel + 1 // incraDcat to next lerc! lO 

ea^ 



Id contrast, more expedient (but less thorough), high-level 
testing may be performed by: 

15 



fonctioQ Setflbsi( iLevel ) 

i>=0 

while < i < NumOfKkls ) 
Child = Childienl i ] 

Child.SctfTc5t( flLercl ) // just test single )cvc\ 20 
i = i + 1 

eod 

end 



Duiiog aeatioD of the dialog at nintime. the Message 
Engine traps the OreateWindow message for the dialog of 
interest (which tfie Model Manager has registered an interest 
in). In ^ manner, the Model Manager 645 receives noti- 
fication from the Message Engine 640 that the dialog is 
about to be created. Upon receipt of the notification, the 
Model Manager locates an existing model of the dialog. If 
a model is found, the system is instnicted to load the dialog 
and execute it, whereupon the Init( ) method of the BaseDlg 
class is invoked. Init initializes the Moniker, thereby creat- 
ing the live link to the actual dialog. Also during Init (as 
shown above), the children are asked to bind themselves to 
thdr ccffresponding screen objects. If one of ttte children is 
a checkbox, for instance, it becomes bound to the actual 
checkbox on the screen. 

The opposite of Init is Detach. Upon the Model Manag- 
er's receipt of a message that die dialog is about to be 
removed from the screen (upon occurrenoe of a Destroy- 
^ndow message for the dialog), the Detach method is 
invoked for freeing memory allocated for the BascDlg 
instance which had been created. The Moniker for the dialog 
is also freed (set to 0). 

This process will be illustrated for the confirmation mes- 
sage box dialog 700. For the dialc^ 700. a nxxld may be 
constructed from the following class definition, derived 
from BaseDlg: 



class ConfimifttioDDlg of BaseDlg 

ButtoD Qui (SeltlOl) // line 2 

ButtDD No ( Sel^ 102 ) 

Button Cancel ( Sel^ 103 ) 

Static ILcTbit ( Selt -1 ) // line 3 

NuDOfKkfe = 4 

// Component array 

Coniponents = ( NumOOCids ] 

Compoottitsf 0 I s Oui 

C uu4 * ou mts| I j = No 

Coai()onents| 2 | = Cancel 

Componentsl ^ j = Text 

Children = Compoocnts 

end 



Hic first line declares a class, ConfirmationDlg. which is 65 
derived from BaseDlg. the existing class. As shown alwve, 
each ATM includes a component array containing all its 



26 

elements. The member functions of the BascDlg class 
manipulate these components once they have been con- 
structed. ConfirmationDlg inherits the data members and 
member functions of BaseDlg and instantiates the list of 
elements for FIG. 7A. as shown in lines 2 to 5 above. Oui. 
No, and Cancel represent objects within the confirmation 
dialog 700 which are instances of a Generic Element Model 
(GEM) of type Bunon. 

In an cxcn^laiy embodiment, each GEM (described in 
detail below) takes two parameters to construct itself: a 
reference to the parent dialog (Self) and a unique identifier 
(either its pre-existing resource id. or one derived by the 
system). In the present example, the Yes button 710 on the 
message box 700 has been represented by an identifier called 
Gui in order to emphasize that there are no assumptions 
about textual information made in the ATM. The object Oui 
loads its expected label text (the text string **Ycs") from the 
Resource Database during initialization time, consequently, 
the ATM above can represent different language versions of 
the Confirmation dialog without any modifications. The 
language difference is enc^sulated in the Resource Data- 
base (described below) which is generated autoroatically. 

As shown above. ConfirmationDlg itself is a class defi- 
nition. To use ConfirmationDlg at runtime, an instance is 
created. In an exemplary operation of the preferred 
embodiment, an instance (variable). ActiveDlg. of the Con- 
firmationDlg class is created at runtime. More particularly, 
the instance is created when the Model Manager 645 detects 
thai the actual Confirmation dialog has been activated, as 
shown by the following test script instructions: 



ConfimatnoDls ActivcDlg( ) // Instantiate ActiveDlg 

ActiveDlg Jnit( ClassName, Caption, 

Application, Resoivceld > // Tnitializo 



When instantiated, ActiveDlg (or mOTC specifically, its class 
constructor) loads ttie expected attributes for its components 
from the Resource Database 620. ActiveDlg also loads its 
own attributes, such as Its expected caption and location/ 
size, from the Resource Database as well. In this manner, 
each con^nent of ActiveDlg (as well as ActiveDlg itself) 
binds itself at initialization to the actual screen object which 
it represents. 
D. Resource Database 

The Resource Database 620 stores expected or baseline 
Information about the objects referred to in ATMs. Recall 
that the ATMs consist of instances of Generic Element 
Models. The Resource Database is where expected attributes 
of these GEM instances, such as label text size, color, and 
the like, arc stored. Thus, the database serves as an inventory 
of all resource information for an application under test 

By storing object attributes in a database, the need for 
"hard coding'* textual or positional information within ATMs 
or within test scripts is eliminated. This is particularly 
advantageous because any textual or positional assumptions 
about a UI element often change, especially when the 
application is to be localized (i.e.. translated to different 
languages) for several international versions. In this manner, 
the need for altering the ATMs or the test scripts every time 
the text label for a UI element changes is eliminated. 

In a preferred embodiment, the Resource Database 620 
itself is implemented using object database methodology. 
For instance, an exemplary resource database may be con- 
structed using a single table defined as follows: 
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Field Name 


Type 


Descripfkm 


Uniqfueld 


Stnng 


Key fitld which uniquety identifies an object 


Label 


String 


The tni aisoetated with an object 


Parcni 


Sums 


The object's parent nanie 


PrefenedName 


Serins 


Variabk name used by the Model Genenlor 




to instantiate this object as 


DefaultSute 


Inicficr 


Defaub state of an object (cbeclced, srayed and 






the like) 


DimeasioD 


String 


Expected location of this object rebtrve to its 






parent origin (xl, yl, r2, y2) Ebmiai 


Attributes 


Binary 


Misc. attributes to be tested 


Pictwe 


Binary 


Screen shot of the object prefexabty in a device 






tDdepcodenl fbimat 



The table is keyed by (indexed on) the Uoiqueld and Label 
fields. Some fidds arc multi-puiposc. depending oo what 
object is stored in the record. For a menu item record, for 
instance* the Dimension field stores the order of the item 
within its popup menu. Further description of the helds is 20 
provided hcrcinbelow. during presentation of the Notepad 
example. 

E. GEM library 
1. Overview 25 

A Generic Element Model or GEM is perhaps best 
described by way of example. Consider an application 
program such as a Desktop Publisher (DTP) application. The 
^>plication may be deconqrased into its major UI conqx>- 
nents: Menus, Dialogs, ToolBar, Client Windows (which 30 
indude scroll bars and system menus)* and a Status Line. 
Each con^ncnt can be broken down further. Menus, for 
instance, can be further reduced to four subtypes: top level 
pop-up menus, system menus, menu items, and side cars 
(**fly out** menus). The entire menu tree of any application 
can be descril>ed as instances of these four types of menus. 
Each one of these four types of menus can then be modeled 
by four coaesponding types of Generic Element Models. 
Using these four GEMs. ATMs can be built which collec- ^ 
tively represent the entire menu tree of the application. Thus 
given a small numba of GEMs, one can btiild ATMs which 
represent the user interface of very complex applications. 

As described above, a GEM encs^sulates the behavior of 
iiredudble user interface elements sudi as push buttons. 43 
checkboxes, iistfooxcs. menu items, and the like. When a 
GEM is instantiated, it takes two parameters: a reference to 
its parent and a resource id which uniquely identifies this 
G^A among its siblings. During construction time, the 
GEM loads its expected results from the Resource Database 50 
using, in an exemplary embodiment, a key consisting of its 
parentis unique id concatenated with its own id. The GEM 
binds itself to the actual UI dement on the screen which it 
represents, when requested to do so by its parent At this 
point, the GEM can be instructed to run a self test 
("SclfTest** method) on itself by singly conqiaring its 
expected attributes (loaded from the resource database) 
against its actual attributes (retrieved from the actual de- 
ment on the screen which the GEM represents). ^ 
Z Detailed construction 

In a preferred embodiment, all GEMs are derived from a 
base class, BaseGEM. which encapsulates the basic func- 
tionality oflfered by a en^ or **facdess** UI element such 
as processing a single or double mouse clicks, or getting 65 
input focus. BaseGEM may be constructed from the follow- 
ing class definition: 



cUss definition 
f BaseGemC Pops. Rcsid ) 
//Begin oonstructor 

PoreotPtr - Pops //Reference to parent 

PaicDtWHodl = 0 //Parent Window Handle 
Id K ResU //Unique kl for this GCM among its 

siblings 

Mcniker = 0 //Live link to the actual UI ekmcni on 

screen 

ObicctType =0 //Type of this GEM 

//Ttese are expected values fetched hum the rcsome data base 

Label =0 

PaientName = 0 

DefState - 0 

Location ° 0 

Shortcut = 0 

//End cons true COT 

functioo BindC ) 

y/Loxj expected values from the resource database 
DefeuhsljoadDat^ Bsps.Id -i- " " -f Id, Label, PareatNafne, 
DefStaie, Location ) 
Shortcut - GetNmemonic( Label ) 

//Bind to the actual UI element on screen 
Moniker = ParentPtr.Monikcrf indltcmC Id ) 

ParentWHodl « ParentPtr^oniker.WinHaodle 

cod 

fuactioo DetachC ) 
Moniker 

end 

fuiKtiafi Select( ) 

if (Shortcut = 0) 
return 

end 

Kcyln( ParentWHndl, "iALT}" + SboitCut ) 
f/KeyM ) resides in Tbst RIL 630 

and 

fimctiaii Cliclc( ) 

Moused jck( Mdmker.WinHandle, LeftButtm ) 
//MouseCtick( ) resides in Test RIL 630 

et^ 

fuiKtioa I>bK:3ick( ) 

MouseDblClickC Mooacer.VmHandk, UaButtoo ) 
//MauseI>blClk:k( ) reskte in Test RIL 630 

end 

£uiM:(ioo RijlitClick( ) 

MouseClick( Mooiker.WinHai^, RigbtButton ) 
//MouaeClick( ) resides in Tbst RII, 630 

end 

fuiKtioo RigbtDbICticfc( ) 

MouseDblClickC Moojker.WTinKaDdk, RightButtoo > 
//MouseDblClick( ) resides in Test RIL 630 

end 

KeyIiito( Chars ) 

Keyln( Moniker. WinHandk, Chais ) 

end 

ftinctioaIsA( ) 

return Objecfiype 

end 

fonction C^XureC ) 
//Viztual function 

//Ovenkle w/ capture routine speci6c for object 

end 

Cunctioo HqsFocus( ) 

DlgHiKll - FaidIheWiDdow( E^arenlPtr.Caption ) 
return MooikciJocus 

end 

fimctioo IsEttabIfid( ) 

return bWtfxkmEoabled( Moniker. WinHandk; ) 

cui 

. fUncttoo GEMTest() 

Bist^Start ( IsA(), Id ) 

Biat.Verify( "'Parent Name", ParcntNanK, 

ParentPcr.Mooiker.Caption ) 
Bist.Verify( "Location", Location, MoniketGeO^atVocC ) ) 

eixl 

etkd //End class definitioa of BaaeCem 



As shown above. BaseGem includes data members of a 
parent pointer, a parent window handle, a unique tdcntiiier. 
and a "Moniker**. The parent pointer or ParentPtr is passed 
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in (to the coostruccor) at initiaUzatioa; for a dialog, the 
dialog passes in "'self* (i.e., passes in a pointer to itselfj. The 
parent window handle (Parent WHndl) is sctto the window 
handle of the parent pointer's nionikcr dunng operation of 
the bind function. The unique ideotlfier or Id is a way to 
identify a particular control among its siblings. This may 
simply be the resource identifier (p*ovided for Windows), w 
it may be an identifier assigned by the systenm. Again, this 
is passed in by the dialog at creation. The Moniker is a 
handle or live link to the actual UI element on screen. The 
object type or Objecfiype indicates a windows type, such as 
checkbox, pushbutton, and the like. 

The class also includes dau members for stcH'ing expected 
values for the object (fetched from the Resource Database): 
LabeL ParentName, DefStatc. Location, and ShortCut The 
values for these are fetched from the Resource Database 
upon instantiation by calliog the Defaults.LoadData method; 
Shortcut is detennlned from analyzing the Label (e.g., menu 
item label of &Fiie indicates a Shortcut keystroke of Alt-F). 
During self test the actual values may be compared to these 
expected values. 

Also shown. BaseGem includes class methods or func- 
tions. The Bind( ) function binds the object to its actual 
screen object In particular, the mediod en^loys a Windows 
Id to return a unique handle or '*Monikcr^ for the screen 
object A corresponding I>ctach( ) function is provided for 
detaching from the screen objecr, the Moniker is reset (to 
zero). Other class methods are provided for simulating user 
events. For instance, tiie CIick( ), DhlClick( ). RightClick( ), 
and RightDblClick( ) methods perform their respective 
mouse clicks, by sending the corresponding Windows event 
message to the target object Select( ). on the other hand, 
keys in the shortcut (eg., keyboard accelerator) for the 
object 

Other types of GEMs may be derived from BascGEM. A 
deckBox class, for example, may be derived. (ZheckBox 
inherits all the ci^abiiities cf BascGEM and adds any 
behavior unique to it It may foe constructed as follows: 



chss Chec]cBax( Pops. Resid ) of BascGEM{ Pops, Resid ) 
Objecfiype = •CheckBox** 
// Get the Gtale (tf cbe Cbockbcoi 
fuoctioD OetSuie( ) 

if ( IsDlgBunoDCbeckttK PaienrWHoU, Id ) = 1 ) 
// Note lADl«Butt)ooChocked( ) b sld Wm API (call) 670 
return 

else 

return "t)" 

end 

end 

fuDction SclfTestC ) 
G£Ml£sr( ) 

Bist\ferify( -Leber, Label, MoniiBr.Cttptioo > 
PrrvScate - OetStale( ) 
Click() 

BistNooEqual^ '^Changixv State", PtcvState, OetState( ) ) 

CUcW) 

BistJ>oiie< ) 

end 

fimctkn Capnire( ) 

dbDictiottary Attribiites( ) 

// dbDictiooaiy b test obrjoct provided by Test RIL 
AttributesAddEctryf I^P, Bhloaiker.Captioo ) 
Attributes.AddEDliy( *lx»cation'\ 

Moiiikerl>cft+*'r+Moiiikcr.Tbp ) 
AliribiitBt.AddEctry( "State", GctState< ) ) 
( etui 11 Atlnbutes 

end 

end 



As shown. CheckBox is a derived class and indudes state 
behavior specific for its type, namely Xhecked" (sUte "P) 
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or "Unchecked" (state for a CheckBox, Since the 
CheckBox knows about its own behavior and attributes, it 
includes nxethods for handling these specifics. For instance. 
CheckBox includes a GetState( ) method which returns 

5 whether the checkbox instance is "checked** or 
"unchecked " CheckBox adds its own Selfrest( ) function, 
which runs the GemTest( ) function (standard self test) as 
well as njoning additional tests specific foe a checkbox (i.e.. 
clicking Itself and comparing its resulting state with its 

10 previous sUte). Capture( ) function for capturing the 
attributes of Itself. SpeciiicaUy for a dieckbox. this entails 
capturing infc^mation about its Label (i.e.. text displayed 
widi the checkbox) and its state (whether it is "checked" or 
**unchecked"). These njay be stored as entries in a database. 

15 3. GEN Functionality 

GEMs will now be summarized in terms of their specific 
functionality. In a preferred embodiment GEMs include the 
following fundamental functionality: Self load. Self (est 
Binding to screen objects. Attribute capture. Next state. User 

20 interaction simulation, and Resource tracking. Eadi will be 
described in turn. 

(a) Self load 

GEMs contain no information about their charaaeristics 
(e.g.. text labels) in their declaration or definition. Instead, a 

25 GEM loads its characteristics from the Resource Database 
during construction. Each GEM (which is a derived instance 
of a BaseGem class, presented above) is consfimcted with a 
unique resource identifier (Resid). Thus whoi a GEM is 
instantiated, the object containing the GEM passes a unique 

30 key to the constructor of the GEM. The constructor uses this 
key to load in the GEM's expected properties from the 
Resource Database: 

Defailts f >oadI>gta(fcpsJd+"«*'+M, Label, PaientName. DefState, 
Locatkm) 

Each GEM is constructed only on an as-needed basis. 

(b) Self test 

All GEMs have a SelfTest member function. SclfTcst 
^ enables the GEM to test itself by comparing its character- 
istics to rht actual element on the screen that it represents. 
The basic test includes checking the position, label, parent 
name, and default state of the element A CheckBox dass. 
for instance, may include the following SelfTest class 
method: 



' fuDCtiosi SelfTestC > 
GEMTestC ) 

BbtAfcrify( XabcF, Label, Moniker.Captioo ) 
PrevSaic = OctStett( ) 

BistNbi£ciual( "Cbangtog Stale". PicvStale. GccState( ) ) 

Click() 

B 'utDca^ ) 

CDd 

55 

As shown, the Checkbox.Selflbst method begins by calling 
GEMTcst( ). whidh verifies the position and parent for the 
object. SelfTest then verifies the text label fw the checkbox 
screen object Finally, the SelfTest mctfiod proceeds to test 

60 the checkbox with mouse click events. Here, the cuaent 
state is saved (to Prevstate). Then, a click event is executed 
(by calling the inherited Click( ) nacthod for the object). At 
this point the SelfTest compares the state of the object with 
the previously-saved state. As a checkbox functions as a 

65 toggle, its now-current state (i.e.. after receiving the click 
event) should differ from the previously-saved state. This is 
confirmed by: 
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Bisi.NanEqua] ("chanpng Scatc**. Prevstate, OetSt8tc( )) 

If the states are instead equal (i.e.. the cheddra oa the 
scTcea did not toggle), the lest will fail. Upon completion of 
the test, the diecktox objea is restored to its jrevious stale. 

In this fashion, all checkboxes of a program may test 
themselves to assure they arc not defective. In addition to 
testing display attributes and rece4>t of input events, addi- 
tional tests can be added to GEMs at any time in the QA 
cycle. When a test is added to the self test section, all 
instances of that GEM will automatically include the new 
test as welL 

(c) Binding to screen objects 

GEMs can attach themselves to the actual object on the 
screen that they r^escnL This ability to bind to screen 
elements enables any given visual clement on the saccn to 
be examined at runtime, greatly increasing the level of 
observability offered by the test automation system. 

(d) Attribute c^>turc 

A GEM can construct a container object which captures 
the attributes of the actual screen element the GEM repre- 
sents. This container object is an instance of the standard 
C++ dictionary class with an extra feature of persistence. 
The attributes of the screen clement can be stored in a 
database (e.g.. in the Resource Database) for later reference 
and comparison. 

(e) Next state GEMs may contain knowledge of what the 
next state of the program will be after the control the GEM 
represents is selected. For cxan^le. when a menu item is 
selected, a dialog box might appear. In this case, the menu 
item and the dialog box are related. As another exan^e. 
clicking an OK button should cause the bunon to tell ixs 
parent {It., the dialog box containing the button) to destroy 
itself. 

Next state relationships among GEMs are established 
using links within ATMs. Maintaining links among related 
GEMs in practice usually ptovcs prot>lematic and inefficient 
however. Therefore the burden of *1cnowing- the next state 
can be disabled within GEMs and transferred to a higher 
level which in this system is the Model Manager. 

(f) User interaction simulation 

Each GEM can simulate any possible operation that a user 
would perform an any given UI element such as a mouse 
dick, to geaing focus, pressing a key, and the like. As shown 
above (in the BaseGEM class definition), for instance, a test 
script may simulate a click event at an object by invoking 
dial object's Click( ) method. 

(g) Resource tracking 

GEMs can monitor resource usage. If there is a sudden 
drop oc leakage in overall system resources, for example. 
GEMs may log warning messages. 

F. Model Manager 

The Model Manager 645 functions to monitor the active 
state of the application under test and load the a^^opriate 
HKKlel of the application under test at any given state. The 
Model Manager provides a key benefit Instead of keying 
the entire nKxlel of an application under test in memory, only 
a model corresponding to the active or live portion of the 
q>plication under test need be loaded and executed. This 
approach yields improved pcrfomoance and decreased intru- 
sion over the application being tested. 

The approach also frees the script develc^r from know- 
ing the instance name of eveiy single component within the 
plication. Consider, for example, the cormnands for bring- 
ing up a file open dialog and clicking the OK button: 



Fa«KkaaOpeo.Sekct( ) 
FU<OpeiiDialQg.OKrikk< ) 

5 

In the above code, the script writer must know that after 
executing the first line, the resulting File Open dialog which 
was activated is referred to as FilcopcnDialog. Kcq}ing 
track of the names of every component within a large 

10 application is tedious and error-prone. Moreover, the 
instance FUeOpcnDialog must be instantiated even though 
the script may never use it. 

In contrast the following code performs the same as the 
one above, yet incurs much lower memory overhead and is 

15 easier for the script developer to nuuntain: 

FdeNknu.OpeiLSelect( ) 
ActiveDte.OK.aick( ) 

20 As shown, once the first line is executed, a global variable 
(ActiveDlg) is automatically constructed by the Model Man- 
ager 645 by loading and executing the ATM whldi models 
this dialog. The Model Manager can also instruct the Model 
(jcnerator to create a model on-the-fiy if one does not 

25 already exist. 

G. Model Generator 

The Model Generator 625 generates ATMs 615 and the 
Resource Database 620. The Generator may employ 
resource information embedded in a program, live data on 

30 the screen, or a combination of both. In the event that all the 
necessary infomoation is not available in a program resource, 
a control script may be constructed to take the application 
undo- test into necessary states so that the model generator 
may generate the appropriate ATM and Resource Database 

35 entries. 

The Model Generator 625 also provides infonoation 
about what changes were made between the current build 
and the previous run. In addition, the Model Generator 
shields old scripts from breaking (ie., incurring errors) by 
40 using a fidd in the database called preferred name. 
Application Modeling: Windows Notepad ^plication 

The method of the present invention for modeling a 
application will now be illustrated using a wcU-known 
application — Microsoft Windows Notepad. In this manner. 
43 the reader may focus on the teachings of the present inven- 
tion without distraction from a complex plication. 

The creation of an Application Test Model (ATM) for the 
Windows Notepad plication is illustrated in FIGS. 8A-D. 
In FIG. 8A, the interface for the Notepad ^)plication is 
50 shown. The interface includes a main or application window 
800 having a cs^on bar 801. a menu bar 820, and a client 
area 840. Menu bar 820. in turn, invokes a plurality of 
submenus, such as submenu 830. 
A- Menu 

55 As shown in FIG. 8B, the menu bar 820 and its subnaenus 
may be deoonq>osed into a resource file 870. Menu resource 
file 870 includes ''popup" sections defining the submenus 
which are attached to the menu bar 820. Submenu 830. for 
instance, is defined by popup section 875. Thus as shown. 

60 the menu bar 820 and its submenus may be decomposed for 
tracking ixs individual elements. The decomposition into 
Application- ^>ecific Tfest Model (ATM) may be accom- 
plished either by reading resource data from the EXE file 
(static method), or by executing the EXE file and inquiring 

65 about menu informatioo (from the running application dur- 
ing runtime). A Model Generator im^demented using the 
latter method provides an added advantage since it can 
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extract dynamic mcou attributes (grayed, checked, and the 
like) from the appUcatioD. These attributes are gCDcrally doC 
available in the resource flic. 

The method for generating menu ATMs using the 
dynamic approach is illustrated in FIG. 8C. At step 881. the 
^plication under test is launched Next at step 882. the 
application's window handle is retrieved. From the window 
handle (he menu handle can be detennincd; this is indicated 
by step 883. For each top level menu, the following steps are 
performed at step 884. At step 884 A, an unique id is 
constructed for this top level menu. At step 884B. the 
resource database is searched for the record under this id. At 
st^ 884C the top level menu string from the menu handle 
is retrieved. A preferred name (if any) is also retrieved at step 
884D; otherwise, a name based on the menu string is 
synthesized (e.g.. 'TileMenuATM'* fa menu item of *Tilc"). 
Using the preferred (or synthesized) name, a class for this 
poptip menu is declared at step 884£: 

clus FileMenuAIM (Parent, Id) of PopUpMenii(Pareiit, Id) 

When the dass is instantiated, a reference to parent is passed 
as the Parent parameter, and this menu*s unique id is passed 
as the Id parameter. At step 884F. the information for this top 
level menu in the Resource Database is updated, and at step 
884G any discrepancies (changes between last run and this 
run) arc logged in the log frle. 

For each submenu, the following steps are performed at 
step 885. At step 885A, the cmenu striiig> and <menu ld> 
of the menuitem are retrieved. A unique id for this menultem 
as determined at step 885B. based on its parentis id and this 
menu item's id. At step 885C. the system looks up the record 
coiresponding to this unique id in the Resource Database. At 
st^ 885D. a prefdred name (if any) is retrieved from the 
I^cfciTedNanie field (or is synthesized based on the menu 
string). This is used, in turn, at st^ 885E to Instantiate a 
variable of type Menultem as a data member of this ATM 
dass: 

Menultem New(Sel/. 9) 

The fiist parameter is a reference to this instance of die AIM 
class; the second parameter is the cmenu ld> of this menu 
item. At step 885F. the record in the Resource Database is 
updated. An exemiriary record for the FilelNcw menu item 
may be constructed as follows: 



Uniqtie Id: 


Notepad,*!^ 


Label: 




Parent: 


&File 


PrefienedNamc: 


New 


Sate: 


ioteger deoocing the state which is 




enabkd, not grayed^ not checked 


DimcQskm: 


1 (denoces die poshkm of diis menuiteni 




within (be popi^ menu). For menu items, 




the Dimension field of the Rcsouicc 




Database is used to describe the 




positioD of the voem item 



Hnally at step 885G, any differences in the log file are 
recorded. 

The menu class. FileMenuATM 915, is constructed for the 
menu bar 820 of the Notepad application as shown in FIG. 
8D. FileMenuATM is a derived class of PopupMenu — a 
Class which encapsulates the behavior of a popup; its rela- 
tion to resource information 910 is shown. In a similar 
manner, a menu class for the Edit menu, EditMcnuATM. is 
constiucted from the resource Information of the Edit menu 
of the Notqjad application, as shown in FIG. 8E. 
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B. Dialog 

When the user invokes a FHellOpen command (e.g.. by 
selecting ^'Opcn*" from the submenu 830). the Notepad 
application 800 displays the Open dialog 900. shown in FIG. 
3 9A. The dialog 900 includes a plurality of screen objects. As 
shown in fuither detail in FIG. 9&. the dialog 900 comprises 
a window 911 with c^>tion bar and includes the following 
children: static text fields 912. 915. 917. 922. 923. edit text 
field 913. list boxes 914. 919. combo box 916. 918. and 
buttons 920. 921. Such a dialog is defined by the following 
resource information: 



1S36 DIALOG LOADONCALL MOVEABLE DISCARDABLE 56, 24. 
264. 134 

15 STVLE DS_MODAIJTlAME I WS_POPUP I WS.CAPnON I 
WS_SYSMENU 
CAFTION -Open'* 

F0^^^ 8, -Hew- 

{ 

LTEXT -Fd« AName:", 1090, 6, 6, 76, 9 
EDITTEXT 1152, 6. 16. 9a 12. ES_JVim>HSCROLL I 
^ ES_aEMC0NVEKT ! WS_B0RDER I WS_TABSTOP 
LISTBOX 1220. 6, 32, 90. 68, LBS_StANDARD t NOT 

LBS_NOTIFy I LBS_OWNERDRAWFDCED I 

LBS_JlASSnaNGS (LBS_J)ISABLENOSCROLL I NOT 

WS_BORDER I WS_TABSTOP 
LTEXT -ADiPBCioriesr, -1, 110. 6, 92, 9 
25 LTEXT " 1088, 110, 18, 92, 9, SS_NOPRmX I WS_<a(OUP 
USTBOX 1121, 110, 32, 92, 68, LBS_STANDARD t NOT 

LBS_KOTIFy LBS_OWNERDRAWFDCED I LBS_HASSTRINGS I 

LBS_J)ISABLENOSCROLL I NOT WS JORDER I WS_TABSTOP 
LTEXT -List Fiks of ATyptr, 1089, fi, 104, 90. 9 
COMBOBOX 1136, 6, 114. 90, 36, CBS_DR0PDOWNUST I 
30 CBS_jVUTOHSCROLL I WS_BORDER I WS_VSCROLL I 

WS_TABSrTX3P 
LTEXT .*T>ri&ve$:", 1091, 110, 104, 92, 9 
COMBOBOX 1137. 110. 114, 92, 68, CBS_DROPDOWNLIST I 

CBS_OWNERDRAWFrXED I CBS^AUTOHSCROU- I 

CBS_SORr ( CBS_HASSniJNGS I WS_BORDER \ 
35 WS_VSCROLL I WS_TABSrOP 

DEFPUSHBOTTON •OK", 1, 208, 6, 50, 14, BS^PEFPUSHBUTTON I 

WS_OR0UP I WS_XIVBSTDP 
PUSHBUTTON trancer, 2, 208, 24, 50, 14. WS_GR0UP I 

WS_XABSTOP 

PUSHBUTTON "AHcliT, 1038, 2C8. 46, 50, 14. WS_GROUP I 
^ WS^TABSTOP 

^ CHECKBOX -ARcad Only", 1040, 208, 68. 50, 1 2. 

BS_J^irrOCHECKBOX I WS_OR0UP I WS_TABSTOP 

I 



Application-specific Testing Model (ATM) generation for 
the dialogs of the Notepad j^lication can be accon^>iished 
using the dynamic method as well. In order to bring up each 
dialog of the Notq>ad applicatioii. a small control script is 
constructed which **walks** the menu tree, brings up each 
dialog, and invokes the dialog model generator to create 

50 ATMs for each dialog. 

Rcfaring now to FIGS. 90~D, Model Generation for 
dialogs, using the dynamic method 950^ is illustrated. In st^ 
951. the following tiles are opened: the Resource Database 
for updating, a Script file for writing, and a MapFde for 

55 reading. (Ms^Filc provides a mapping from the type of UI 
elements on the screen to the coiresponding GEM type). In 
step 952. the dialog to be modeled is brou^^t up (on tiie 
screen) and a live link is established with the dialog, using 
cither a window handle or the Test Port At step 953. the live 

60 linlr is used to determine actual caption, class, and unique id 
for this dialog. If. at step 954. Che unique id (Uniqueld) is 
known, the method proceeds to step 957. Otherwise, the 
method scarves the Resource Database, based on caption 
and/or class of this dialog, in an attempt to locate the record 

65 corresponding to this dialog. If one is found (step 956), the 
method proceeds to step 957. If not found, however, a 
unique id is assigned to this dialog at step 958. with a new 
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record being created for this dialog in the Resource Database 
(indexed by the unique id). 

At step the values in the record (corresponding to this 
dialog in the Resource Database) are compared to the actual 
dialog attributes (as displayed on screen). Any differences 
are logged; the record in the database is updated. At step 
959. a class definition statement for this dialog is generated 
in the script hie. 

Next, the children controls are processed. At step 961. the 
(next) diild control within this dialog is located. If child is 
NULL (no more children) at step 962. the method proceeds 
to dep 967; otherwise, the method goes to step 963. At step 
963. a live link is esublished with the child control 
(window). Based on the info available from the link to diis 
child window (e.g.. type. id. and label), the following values 
arc assigned at step 964: 

A) <GEM Typc> gets iu value from the MapFile based on 
the type of this child window. If no mining available 
<GEM type> set to BaseControl. 

B) <Id> is set to the unique id. usually resource id. for this 
control. 

C) <PrefcrredNafno is set to the value under field Pre- 
ferredName of the record in resource database coire- 
sponding to this control. If none found, synthesize a name 
based on the label or type of this control 

At step 965. a line is generated in the script hie to instantiate 
a variable called <PtefeCTedName> of type <GEM Typo 
widi id <Id> as follows: 

<GEM lypo <P*efenedN»iiit> (Self, <Id>) 

At step SW. values in the record from Resource Database 
are compared to corresponding ones for die actual attributes 
of this control. Any differences are logged, and the database 
is updated accordingly. After this stq>. the method loops 
back to step 961 for processing the next child (if any). 

At step 967. a line is inserted into the script denoting the 
number of children generated: 

NuniOfiCjd^:<iniinber of child windowt or o(»itroItf> 

At step 968. a component array for this dialog is aeatcd in 
the script by enumerating ail components of the dialog. 
Finally, the following two lines arc written to the script file: 



// Wlttfc Children is a rtfemice to the compcneiits of tfae dialog. 
// dukkeo is used is BascDlg class (see above)L 



Statik 


SFiVcNamc 


( Self. 1090 ) 


Edit 


FikNune 


(Self, 1132 ) 


ListBox 


BlesLB 


(Self, 1120) 


Statik 


SDiTccroncs 


( Self, -1 ) 


Statik 


Path 


( Self, 1088 > 


ListBox 


DiroctocyLB 


(Self. 1121 ) 


Statik 


Type 


( Self. 1089 ) 


ComboBoi 




(Self, 1136) 


Statik 


Drives 


( Self, 1091 ) 


ComboBoz 


DnveCB 


(Self. 1137 ) 



36 

-continued 



Buttoa 
BunoQ 
Buttoo 
CheckBox 



OK 
Cucel 
Network 
Help 

Readonly 



10 



20 



cod 



NuiDOfKids= IS 
local Components = t ^fuIDOSCkb | 
Compoocntsf 0 | = SFilcName 
ComponeaitsI 1 | = FifeName 
ConqKnMits) 2 j = FilesLB 
ConqroDcDtsI 3 | = SDxrcctoncs 
CompcHienlsl 4 j - Path 
ConqKnmtal S ) - DiiectoTTLB 
Components! 6 j = Type 
Conionentfil 7 | = 'iypeCB 
CoaqKmentsj 8 j ~ Drives 
Con^ODcntsI 9 j = DnveCB 
Coaq>ooeat8( 10 | = OK 
CofxqxHieatsl II jsCncel 
Compoaents{ 12 | = Netwoxk 
Compooentsl 13 j = Help 
Conq>onettt5( 14 j = RcadOoly 
Children ~ Components 



( Self , 1 ) 
( Self. 2 ) 
( Self. 1037 ) 
( Self. 1038 ) 
( Self, 1040 ) 



An instance is declared as follows: 

FdeOpenDU Active Dig ( ) 

Once testing models for the components of the Notepad 
application are constnictcd, a Test Model ccaresponding to 
the active portion of tfae Notq»ad application can be written 
^ as follows: 



class hIocq)adMocfel( ExcHanK, ModukKame ) of Base Window 

( ExeKame, ModuleName ) 

B&t Editor ( Self, 15 ) 

FileMemiATM FileMenu ( Self, -«r ) 

B(fitMeDU>MM EditMenu ( Self, "#2" ) 

SeaichMenuAIM SearchMcuu ( Self. NB** ) 

He^MeoiuaM KelpMecu ( Self, -<4" ) 

KumOfKids » 5 

k)cal Compoocots = \ NumOfKids ] 
CompooeotEl 0 | = Editor 
C ui up on mtsI 1 j = FikMcou 
CompocentsI 2 j ^EditMau 
CompanentB( 3 j = SeaichMenu 
Compooentsl 4 j = KelpMemj 
Children = CotapoacDts 
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40 



45 end 



SO 



At Step 967, all open files (i.e.. Script file. Resource 
Database, and MapFile) are closed and the method con- 
dudes. 

Following is a san^le ATM created for the Open dialog 
900 by the Model Generates: 

class FileOpenDlg( ) <^ BaseDls( ) 
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As shown, the Testing Model of the Notepad application 
consists of an edit window and instances of AIMs. The 
fomicr is represented by Editor which is an instance of the 
GEM type Edit; the latter represents the top level menus of 
Notepad application. The children array is a reference to the 
components of the Notepad plication. Since the dialogs of 
Notepad are not active when this application is started, they 
are not inchided in the Test Model for this plication. The 
models for the dialogs of Notepad are preferably kep* in 
separate files on disk, only being instantiated by the Model 
Manager on a "demand-only** basis, thereby saving mcnMffy 
and system resources. 

Once Application-specific Testing Models for the Note- 
pad application are ccmiplete. a variety of self tests (i.e., 
more than one level of self test) can be invoked simply by 
executing the following script commands: 



65 



NotepadModel NotePadf "ootepodxxe". -NOTCPAD** ) 
Notepad.SelfItet( I ) // test level 1 
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Notepad.Sdnest( 2 ) // test kvei 2 
NotePBdSclfTesK 3 ) // test level 3 



If self test results arc acceptable, test scripts based on the 
Notepad ATM can be executed. Upoo invocatioa of a test 
script, the Test Runtime Library (RTL) is loaded, the 
Resource database is opened and initialized the GEM library 
classes are loaded, the Model Manager is started, and the lo 
Testing Model of the app under test is instantiated. 

The Model Manager establishes an Aiq^cationlink and 
one or more WindowLinks with the application under test 
and attaches to the ^ropriate Application Translation Units 
(ATUs) as follows: is 



ApplkatiooLink Kotq»dApp( "KOT^AD" ) 
NoteFadAppJ^ctachArU<**WINAnJ.DLL'') 
WindowLmk AnyWindow( NotepadApp, 0) 



These actions enable the CBT Message Engine to hook to 
the target application and monitor messages going to and 
coming from the application under test, thus allowing events 
of interest to be registered The Model Manager typically 
registers an interest in three events for a target aj^cation: 
Window Creation, Window Activation (getting focus), and 
Window Destruction. 

In addition to application-specific messages, the Model 
Manager may also asks the Message Engine to send notifi- 
cations for system events such as Unexpected Application 
Errors (UAEs) or other system wide messages: 



OQ SyB0t9ect.UAE( info ) 

//code bo baodle an uoexpected application oror 35 

eod 



Once the application under test is executed and all events 
of interest are registered by the Model Manager, a test script 
may be executed. This will be illustrated by studying execu- 
tion of the following script 



Nol^)adJnleMeiLiLOpen.Select( ) // Line I 
ActiveIHgJiknaincSet( "tcsLtir ) // Line 2 
ActiveDlg.OK.Cliclc( ) // line 3 



Line 1 executes the code associated with the Select( ) 
monbcr function of class Menultem. This code sets focus to 
die parent appUcatioa (Not^d) and generates the shortcut so 
(e.g., accelerator key sequence) for FllelCDpen menu ( AO'+ 
OF for the English version of the Notepad application). TTie 
shortcut is determined by concatenating the ALT key with 
the short cut keys for Notepad.FileMenu and Not^dJFile- 
Mcnu.Opcn. These short cut characters are set during con- 55 
struction time when the GEMs load their expected data from 
the Resource Database. Notcpad.FileMenu has "&File** as 
its label, therefore its shortcut character is the letter F (first 
character following the & in &Fi]e). By the same token, the 
label of Notepad FileMenu.Opcn is &<>pen so its shortcut 60 
key is the letter O. 

Once line I is executed, the Notepad application receives 
an ALT4F0 key sequence and in turn responds by creating 
the FUe Open dialog (dialog S50 of FIG. 8D). Since the 
Model Manager registered an interest in any window ere- 65 
ation message coming from the Notepad application, the 
Message Engine dispatches this event to the Model Man- 
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ager. Specifically, the Message Engine notifies the Model 
Manager that the Notepad plication is about to create a 
dialog of a specific class with a cation called ^^Open". The 
Model Manager then looks in the Resource Database for 
such a dialog. Based on the PreferredName field of the 
record associated with this dialog in the Resource Daubase. 
the Model Manager determines what file on disk provides 
the Testing Model for this dialog. 

Next, all the children of File (Dpen dialog are created. 
Upon receiving a message indicating that the File Open 
dialog got aaivated (on AnyWindowj\ctivate(info)), the 
Model Manager instructs the Script Engine to load and 
execute the ATM corresponding to the File Open dialog. 
Once this ATM is executed, all the GEM instances in the 
ATM load their expeaed results from the Resource Database 
and bind themselves to the actual screen objects within the 
File Open dialog. At this point, the variable ActiveDlg is 
instantiated and initialized. It represents (he Testing Model 
of die File Open dialog. 

Line 2 executes the Set( ) member function of 
ActiveDlg.FUename. which is an instance of a Edit box 
GEM. The function sets focus to the Filename edit box 
within the File Open dialog and sends the key sequence 
"^sttxt*" to the edit box. Line 3 generates a left mouse dick 
on die OK button (button 861) of the dialog. This leads to a 
window destroy message being generated. Since the Model 
Manager has registered an interest in this message as well, 
the appropriate event handler gets executed, freeing up the 
memory associated with the ActiveDlg and its components. 
Advantages 

The present invendoo provides independence from posi- 
tional and textual characteristics. As shown in the sample 
code above, test scripts assume nothing about the physical 
location or text label associated with the actual object on the 
screen. This is possible because compon^ts which can bind 
to the corresponding screen element dynamically during 
niotime make up the test model. The components can also 
load their expected charactoistics from a database table diat 
stores resource information. 

The present invention provides a built-in self test for 
objects. Once the QA engineer constructs die nK>deI of the 
application, the model tests itself to ensure that the model 
matches the application. Each component of the model can 
also test itself. This self-testing capability serves as an 
acceptance criteria for new versions d the application being 
tested. The system can also enoploy die model of ttie 
application to automatically generate test soipts that test the 
application. The model determines die plication's reliabil- 
ity by randomly testing the application and measuring the 
average time between failures. 

Besides taking screen shots, the sy^em of the present 
invention can capture the visual state of an application by 
saving attributes of each screen element For instance, 
attributes may be saved in a binary field of a database, which 
a QA engineer can analyze further. The engineer can recca^d 
a failure caused by a change in location or size of a screen 
element as a warning rather than a false negative. 

Using the information stored in the Resource Database 
and the Message Engine, the system can perform high-level 
recordings. Specifically, the mouse and keyboard actions 
used to control die application are mapped into high-level 
test scripts. These scripts do not assume anything about the 
location or text associated with screen elements. 

By storing all resource-specific test data in a database, 
localization is facilitated. The test scripts may run on local- 
ized versions of the application without any modifications. 
Also, lest scripts written fcs one GUI platform can run on 



08/21/2003, EAST Version: 1.04.0000 



5.790,117 



39 



any other GUI environment if the Script Engine and other 
components are available in the new environment. Because 
changes in the application are handled by the model, not by 
test scripts, test script maintenance is reduced. 

GEMs of the present invention provide maximum con- 
troUabiUty and observability over the actual screen objects 
that they represent. In pajticular. the user interface is broken 
down into irreducible components which arc modeled to 
provide maximum controllability and observability (over the 
actual screen objects that they represent). The Test Model, 
which itself is built from these components, thus also 
provides maximum controllability and observability. 
Accordingly, testing effectiveness is maximized. 

While the invention is described in some detail with 
specific reference to a single preferred embodiment and 
certain alternatives, there is no intent to limit the invention 
to that particular embodiment or those specific alternatives. 
Thus, the true scope of the present invention is not limited 
to any one of the foregoing exemplary embodiments but is 
instead defined by the following claims. 

APPENDIX A 

Exemplary CBT Messages 

1) mcnuSeiect: 

• Sent wbcQ tn item is highlighted in a puUdowo nicxni. 
. TVanslates WM_MENU SELECT events. 

2) meouCboose: 

• Sect wben an item is cfaoaco from the memihar. 

- lYansUtes WM_COMMAND events caused by menu items. 

3) window Activate: 

- Sect when a window is about to booccne active. 
. Translates HCBT_MOVE events within the CBT hook. 

4) windowMove: 

- Sent wbcfi a window is aboot to be moved. 
> Translates HCBT_MOVE events within the CBT hook. 

5) windowSbow: 

- Sent when a window is about to be miniinizM, rTgyhni/rd or 
te a tored. 

• TVansUtes HCBT_3aNMAX events within the CBT hook. 

6) vindswClose: 

- Sent when a window a about to be closed. 

• TVHQsUles W\L-CLOSE events. 

7) nioiiseEnter; 

- Sent when die mouse potnler enters a windsw. 

• Perfarms Mt-tcstmg duriog WM_MilhOCUS events. 

8) mouseLeave: 

- Sent when the mouse pointer leaves a Window. 

- Generated at Che same time as ihe motiseEnlier message. It is 
(fispatcbed to the window that received the previcus mouseEaler 



9) UKMiseClick: 

- Sent when a axwae butban b clicked or dcnble clicked. 

- TVanslaies WM_{NCy {U R JBUITONDO WN and 
BUTTONDBLCLK events. 

10) anjEvenl: 

- Sent when any other CBT message is leccivod, but no 
oofTcspondxcg script pkmI^'V is This is the default mrsiage 
for each handler... 

11) appUcatkn^Tlose: 

- Sent wtra the ^ipiicatkxi ts abou to tenniiiate. 

- TVansUies WKL-GLOSE event. 

12) winHelpMessage: 

- Sent when the ^mdows 3.1 he^ engine scods infonnatioo to ihe 
CBT system. 

• This message is generated when WinHetp calls a public fimctioa 
within the Message Engine. 

13) editEoter: 

- Sent wtra an EditboK is about to receive the input focus. 

- TYanslatcs HCBT_SETFOCUS events within the CBT hoot 

14) edilLeave: 

- Scot when an Editbaz is about to lose ttie input focus. 

- 'DanslalBS HCBT_SETFOCUS events within the CBT hook. 

15) edjtChar 

- Sent for each keystroke typed within an Editbox. 

- Translates WlkC-CHAR events. 
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ExemplaTy CBT Messages 



10 



20 



25 



33 



40 



16) listboxEoter: 

- Sent when a Listbox is about to receive the inpul focus. 

- Translates HCBT_SEIFOCUS events within the CBT hock, 

17) listboxLeave: 

• Sent when a Ustbooi is about lo lose the input focus. 

- TiaiBlates HCBT_SETFOClIS events within the CBT hook. 

18) iistboxSekct 

- Sent when an item in a Listbox is selected 

- Trans Utcs WM^COMMAKD events wl»e wParam = 
LBN_SELCHANCffi 

19) listboxDblCbck: 

• Sent when an item in a Listbox is double clicked. 

• Translates WM^LBUTTONDBLCUC events within the Ustbox. 

20) oomboEntcn 

- Sent when a Comboibox is about to receive the input focus. 

. Tmahics HCBT_SETFOCUS events within the CBT book. 

21) combcLeave: 

• Sent when a Combobox b aboot to lose the input focus. 

• Translate* HCBT_SETFOC US events within the CBT hook. 

22) comboChan 

• Sent for each keystroke entered within a Combobox. 

- TVanslates WM_CHAR events. 

23) ccmboSelect 

- Sent wben an item in a Cosdbobox is selected. 

- Translates WM^COMMAND events where wparam = 
CBN_SELCHANaB. 

24) cocnboOblClkk: 

- Sent when an Stem in a Combobox is dstAiIe clicked. 

- Translates WM^XBUTTONDBLXXK events within the 
Combobox. 

25) buttnifaler 

• Sent when a Button ts about to receive the input focus. 

• TVanshles HCBT_SETFOCUS events widiin the CBT book. 

26) butiooLeave: 

- Sent wben a Buttoo is about to lose the input focus. 

- TYaosJales HCBT_SFTFOCUS events wtdun die CBT brck. 

27) buttnnClick: 

- Sent wben a Button is clicked. 

- Trans Utes WM_COMMAKD events where wParam = 
BN_CLICKHD. 

28) scrollEnter 

- Sent wben a Scrollbar is about to receive the input focus. 

- Translates HCBT.SE1F0CUS events within die CBT hook. 

29) scroULeave: 

• Sent wben a Scrollbar is about to Looe the input focus. 

. Translates HCBT-SETFCXUS evcDts within the CBT book. 
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Bxemi>larv CBT Messaae Handlers: 


Message Handler 








Class 


Message Name 


Message Type 


EveotEnfo Object 


T^et Window: 


- mcnuSeiect 


Notify 


Sffcmlnfo 


- menuCfaDose 


Confirm 


Meoulnfo 




- windowActivate 


Confinn 


Windowlnfo 




• windowMove 


Coufinn 


VmPositionlnfo 




• wtndowSbow 


CVi^rfinii 


WiaShowhifo 




• windowCfcse 


Confinn 


Windowlnfo 




• mouseEnftJ 


Notify 


Mouselnfo 




• mouseLeave 


Notify 


Mouselnfo 




• nKNficCljck 


Cbnfijm 


Mouselnfo 




• anyEvent 


Confinn 


WtndowXnfo 


Target 


• apphcatiooClose 


Confirm 


Wmdowlnfo 


Appbcatkxi: 








TaigetWinHelp: 


. winHetp- 


Notify 


WlnHelplnfo 




Message 






TazgetEditboot: 


. ftdifRnt^ 


Confirm 


Windowlnfo 




- editLeave 


Confinn 


Window Info 




- cditOiar 


Confinn 


KeyboardEofo 


Targedisibni: 




Confinn 


Wiodowlnfo 




. EstbcExLesve 


Confinn 


Witxbwlcfo 




• fistboxSelect 


Notify 


Listlnfo 
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APPENDIX B-continued 



APPENDIX D-continued 



EicmrJary CBT Message HandlCT: 



Message Handler 



Class 


Message Name 


Message Type 


Eventlnfb Object 




- UsiboxDblCikk 


Coofirci 


Lisilnfo 


TaigetCoiulo* 


- cocnboEnter 


Caafirm 


Wtaciowlnfo 


Box: 


- comboLeavc 


CoufinD 


Wmdowlnfo 




- comboCbar 


Coo&in 


Keybo2rdln£o 




- comboSdect 


Notify 


Listlnfo 




- comboDblCtjck 


CgnfirtD 


LisOnfo 


TargetBnttoir 


. IxittooEater 


COD&ID 


Wmdowlnfo 




- btittonLeave 


Confirm 


Wmdowlnfo 




• buttonClkk 


Coofinn 


Wmdowlnfo 


TkiyeiScrollbar 


• scrallEnier 


Confirm 


Wlndowlnfb 




• scroULcavc 


Confirm 


Wtodowlafo 



APPENDIX C 



Message Handler Properties 



Mess^ Haodler Class 


Property Name 


Descr^itioo 


Taiget Window: 


- Name 


Tide string of the control. 




-Class 


^^□dows class of (be 
control. 




-ID 


Resource ID of tbc control. 




-Styk 


Style flaj(s of ifae cootrol. 




-Enable 


Wbetber the cootnsl is 
enabled. 




- PtaitioG 


Coordinates of die cootzol 




- Evcndnfo 


Current Eventlnfo object {if 
any) 


Tkrget AppUcatioa: 


- Show 


How the qppbcatioa is 
di^Uyed. 


TajsetWmHelp: 


•Tbtl 


Text SCSI bom or to 
WmHelp. 


TargelBditbox: 


• EditText 


Text oootaiood in the 
Klitbcx 


TaiseO^istbcx: 


• SelectioaliKkx 


bdex of the selected item 
iu the Listbcx. 




• SelectedStrii^ 


•Strix^ which is cuneody 
selecied in the listfaox. 
This is valid ooly if tlie 
Listfaox contains strings. 


ComboDcix: 


• EditText 


Text contained in the 
Couibobox edit field. 




- Selectioulcdex 


Index of the selected item 
in the Combobtn list 




- SekctionText 


StTiQg which is currently 
selected in the Combobox. 
lUs is valid only if the 
Cocnbol)oac oontams strings. 


IkrsetScroUbar: 


.ScroUVUue 


Current position of the 
scrollbar thumb. 



A Sample Lesson Script 



5 //• 

on theControlWodexiiButtOD 
thcChLessooxxil 

end 

end 

script for ^Srmrg' 
10 // 

// Disable the target sppUcatioQ. When the app is disabled no 
// events are dispatched id the CBT 



// 



OVApp.di5abk 



20 



(5 // When the Next button in the control dialog box is pressed, 
// show tbc taisct application, show the first bitmap and 
// goto Che Doxt scene 

// 

oo ti^Comro IWndjJcxtButton 

OVApp.acUv«te(SW_SHOWNORMAL) 

tlKBitmapWndjshowrBMP_ O 
thcCbtLe*soo.per6orm("Scene 1 ") 
end 

end 

script for "Scene P 
// 

// When the Next buttoo in the control dialog box is pressed, 
2^ // enable and maximize the target application, show the next 
// bitmap and goto the next scene. 
// Remember, tfae appticatjoo is still disabled so we don't 
// need to wony about messages fiom it. 
// 

oo tbeControlWDd. oeitBurtoc 
30 OVAppxoable 

OVApp.activale(SW.._MAXIMlZE) 
tUCb(LessaiLpcr{ormr'Sccne2'*) 

end 

end 

acr^t fbf "ScencZ" 
35 ff 

/f Show the bitm^ tar die second scene... 



// 



tieBitm3pWnd.dxw(-BMP_2") 
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// If the target application is about to close, stop the message 

/; 

on OVAppxlose 

OV^^.ftopMess^ 

end 

// 

// Stop aU rij^ mouse button dicks since these will bring \ip 

// a properly inspector. 

// 

on OVApp jnouseClick 

if( 0VApp.evealMDisfUshtBiittC]O ) 
OVApp.stO[Mess4ge 

end 



50 // 



APPENDIX D 



// If one of tfae Properties I Object meoo items is chosen, 
// then sbow the mnaupii ale bhmap and goto the next 



A Sample Lesson Script: 



// Odierwise, stop the mess^... 



illustrates a sample ObjectVision ® tutorial. 



The followtng CBT i 
lesson "OVDcmo" 
script for Initialization"' 
// 

// Create a mess^ handler for the target application. 
// Create a Bitmap Interaction window 
// Create a dialog box control window 

// 

TargetApplicfttion OVApp("0b}ectVisian*^ 
BitmapWindow thcBitmapWDcic ) 
ControlWmdow tbeControIWndflOO) 

// 

^/ Set up a global message handler for tiv EXIT 
// button oo the CST Control window.. 
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on OV/^jnenuChooGc 
tsVUidCboice = 0 

if( OVApp.evf nrlnfo iryniiTd = 69 ) 
tbeBitmapWmd.8bowrBMP_3r) 
bVdidCboice= 1 

ei^ 

tf( OVApp.eventlniojDecuId = 52 > 
tbcBitinapWal.show(-BMP_32*^ 
isV^lidCboice =^ 1 

cod 

if( OVApp.eventbifojDenuId = 53 ) 
theBitmapWrxLsbowfBMP_33") 
b\^didCbDicc = I 

end 

. // 
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APPEKDK D-continucd 



APPENDIX E-conlinucd 



A Sample LeecoD Scripl: 



WindowProiy 



// Tbb caatinucs for cicb mcau item of incciest. 
. // 

iff bVWkJChoicc = 0) 

theCb(LessoapeTforni("ScaieEriOT'') 

end 

iff isVaidChoice = I ) 

tbeCbtLessaapcrfonii('*Scene3") 

cod 

end 

end 

script for -Sce3c3" 
ff 

// Cicate XQESsa^e handkrs for the OK and Cancel buttons in 

// the dialog box in (be taiget applicaiioo. 

// 

TkrsetBuaoD ttwOEBtnfl) 
TargetButtoQ tbeCatDoetBtD(2) 

// 

// If eitber of theses bunoD: is pressed, (bcD 
// go back to aoenc 2. 

n 

oo tt»CaDceIBtD.buttooCtjck 

ibcCbtLajo o-pcrfDnn^ ** Scene 2") 

exd 

oo l3ieOKBtn.buttooCiick 

dxCbaxs9oc.pejfotm(**SccDe2*') 

cod 

eul 

script for -SccocEiror" 

// 

// Show the enoT screen and wail for the 

/y .user to do anything in the target apfrficatioiL 

// 

dMfiitmapWtxl.£faow(^MP_.ERR"> 

on OVApp^^venl 
OVAppftopMessage 
tfaeCbdjessoiL p ei f um< 'Sccne2") 

end 

end// lesson 



AITCNDIXE 

WittfcwPiDxy 

#ifode{_WINPROXY_KPP 
«defiir_WINPROXY_JffP 
#ifodef_CBTOBJ_HPP 
ffinchicfe *ba£e\cbtobj.hpp" 
#eD(£f 

#ifodef_PWINDOW_HPP 
l^hvk '*protocoApwmdowiipp** 
#cixiif 

«ftftKlc(_JTNTERAT_HPP 
ifinchide '*protocoI\piteiQtiipp" 
fcodif 

jft&tlcf CUENT_HPP 
#iachide -lucyVclienLhpp" 
fcodif 

tfdefioe WINDOWPROXY^NUMPROTS 2 
class SHARED_CLASS WintfawProxy : public OrtObject, 

public Pro( Window, 



IjONG IWtsdonvStyk; 
pidjlk: 

WiikJowPioxyfcoos* char 'sttTask, 
const char *stiClass, 
const char *sorTitk); 
WiaJowProxyfHWND hWod); 



to 
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virtual 




virtual 




const; 




/• 




•• ProtWiodow hmcs 


•/ 




virtual 


BOOL 


bStote); 




virtual 


const char * 


char»); 




virtual 


int 


virtual 


int 


virtual 


int 


virtual 


int 


virtual 


const char * 


•); 




virtual 


UINT 


virtual 


HWND 


virtual 


BOOL 


*pTW. 




bAutoDestioy. 


COLORREF igbookT, 


bSubRcct, 




int y» int w, 


inth); 


viztua] 


const cLucyC 


virtual 


BOOL 


bStale); 




virtual 


BOOL 


virtual 


BOOL 


/• 




•* Protltencor methods 


•/ 




virtual 


cLucyObj • 


virtual 


cLucyObj • 


'nitual 


cLucyObj • 



-WDdowProoiy( >; 
SuppoTi2(bPioiocol Albll) 



Visibk(BOOL bFlag, BOOL 

Caption (BOOL bFlag, coast 

XfBOOL bFUg, ini x); 
YfBOOL hFlag, int y); 
WfBOOL bFlag, im w); 
HfBOOL hRtg, int h); 
WimlowClas5(BOOU const char 

WindowResidfBOOL, UIND: 
Haiidle( ); 

Anowfooost d-ucyObj 

BOOL 



BOOL 
inl X, 

pfvoid); 
R)cus(BOOL hFlag,BOQL 

UpdateC >; 



TopcDost(BOCL, BOOL); 



public 



ProtlicratoT 
\ 

protected: 
KIASK 
HWND 
HWND 
char • 
char • 
char • 
in 



hTWgelTask: 

hWncfrarget; 

bCutrltetn; 

strTaskName; 

scrWiDdowNacie; 

strWindowClass; 

iWiiriowld; 



RrstC); 
Neil( ); 

FtDdItem(UlNT id); 
CBT0BJECT_llNFO (WodowProxy. -WINDOWPROXY*^ 
PROTOCOlwJNFO (Wiodowproiy, Info, 
WINI>OWPROXY_NUMPROTS) 
protected^ 

BOOL BiD(froWiKtow(HWND 

hWnd); 

« }; 

#eKlif 



What is claimed is: 

1. Id a con^iutex system, a method for self testing opcia- 
50 tion of a grs^ihical user inteiface, the method con^rising: 
(a) creating for the graphical user interface at least one 
model for testing user ictoface elements, each said at 
least one model being constructed from a set of generic 
objects representing basic user interface elements; 
55 (b) providing each model a link to its user interface 
element; 

(c) storing for each model a set of expected characteristics 
that its user interface dement is to exhibit including 
expected characteristics that each user interface de- 
ment is to exhibit when invoked by a user; 
*° (d) self testing at least one of the user interface dements 
present in 3ie graphical user interface, by perfonning 
for each user interface element to be self tested: 
(1) automatically simulating for the user interface ele- 
ment an action by the user \^ch invokes die user 
65 interface element and observing characteristics for 

the user interface demcot which arc exhibited upon 
invocation; 
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(2) coitq>ariog the observed characteristics with the 5. The method of 2. wherein step (d) includes: 
expected characteristics specified in the model 

linked to the user interface clement; and providing a test script, said test script having a high-level 

(c) if the observed diaractcristics differ from the expected command for asking alJ user interface clement to test 

characteristics. rq>oiting the difference. 5 themselves in turn. 

2. The method of daim 1. furtha comprising: ^ jjjc mctfiod of claim 1. wherein specific user interface 

(f) providing each model with a set of methods far elementsiocludeselectedonesof a menu, a toolbar, a dialog, 
simulating operation of its user interface element; and ^ client-area window, and a status line. 

(g) simulating runtime c^>eration of the graphical user 7 jy^^ metfiod of claim 1. wherein specific user interface 
interfaccby invoking methods for selected ones of the ^^^^^^ .^^^^^ ^^^^^^ ^^^^^^ ^^^3 checkboxes. 



and listboxes. 
8. The method of claim 1. wherein step (d) includes: 



user interface elements. 

3. The method of 2. wherein step (d) includes: 
providing a test script, said test script having high-level 

commands for specifying user int^ace elements 15 determining all user interface elements present for which 

which are to be explicitly tested in a particular a modd is available for self testing. 

sequence. 9. jhe method of claim 8. wherein simulated actions in 

4. The method of 3, wherein said high-level commands j^^jj^^ig ^^^^ 3 input device, 
indudc a general format of: ^ ^^^^ ^ ^^^^ ^p^^^ ^ 

lobjecti. i«:tion| "*P"^ device includes input from a selected one of a key- 



board device and mouse device. 



where (object j specifies a user interface dement and laction) 
specifies a simulated operation for the object 
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